Hello! and Happy 2017!
I am trying to insert (i operation) two pre-made static models for a lite rail stop model. When I drag and drop the models into the scene they look fine. However, when I use the i() operation through a rule...part of the textures are missing. I know the dae files pointing to correct textures because I can drag and drop the models...and I have tried geometry cleanup operation...but still no luck.
Ok, I figured it out.
There was a color() function called on the lane the train is sitting on earlier in the code...I bypassed the color function and the train looks correct.
I hope that was not my bad, not sure if you are using the CS rule.
Can you share the code for the Light Rail stuff? Models? This looks like a pretty good setup. Did you have any thoughts on how to handle the intersection? I think about this problem from time to time.
Hi David! Yes I am using the CS rule. Always modifying (probably not for the better) to these crazy Nashville projects. haha
It was nothing bad on your end. You wrote the "CenterLineReporting-->" to revert to a color() function if the user wants Usage instead of Thematic. For some reason that was throwing off most of the textures in my Lite Rail assets. I just simply bypassed with a boolean..
I will certainly share. I have attached the code, models, textures here.
It is not very accurate or robust..but I primarily just need these things already in place when I go from CityEngine to animation software. Its a huge time saver.
As for intersections...I have just been adding the missing track manually in the animation software by projecting the track texture onto a flat plane that is at the same elevation as the intersection (cheating I know, but I have not found a work around in CityEngine for adding tracks to intersection ...and thankfully I dont have many intersections in this project)
If you would like to add onto CS and try making lite rail mode more permanent that would be awesome. Let me know if you need anything.
This is awesome. Are there any licenses I should know about for the models? Thanks for sharing man! Models and textures are always a bottleneck for a public distribution. I just want to make sure the right people get credited.
Intersections have always been the reason I feel anxious to add this functionality in. However, maybe the understanding that it would only be on the cross section level would be ok for now. I will take a look at this later and keep you updated if I try anything.
Im actually not sure about credits to models. I got those from the Sketchup warehouse for testing and building (except for the small ramp which I made). I will have to look into using/crediting from Warehouse and get back to you.
when the time comes we use it..I will probablly make my own Shader and Rail car (thats my favorite part)...which I will share.
I am actually not sure on this David. I found this thread from Trimble...
However...I think it would be best to create a shader and rail model to use if you are going to send out a CS update.
I will make some cool ones and send it to you.
Yes..your right, it would be cool even without intersection tracks. I have been thinking maybe their is a way to scaleUV() an intersection texture that already has a track based on street orientation and width. Im just not sure where to start.
I am conflicted about it too. Theoretically you can subdivide the intersection to conflict spaced lanes (bike/bus lanes/rail) and the based on the street and its orientation, but it is hard to figure out how to handle things like transitions (when one road narrows into another) and harder yet how to reconnect objects that need to connect at the other end (wires and the like). Matthias did some coding with that in python/CGA to do power lines between buildings in his Favelas model, but a pure CGA solution is difficult because shapes cannot "talk" to one another (right now at least). In addition, do you remember way back when when you could not get an elevated crosswalk? I suspect the same UV orientation issue could prevent a reliable solution of getting an intersection shape to align with the receiving street shapes.
Even worse is thinking about all the stop gap/crosswalk code that would need to be gutted for it to be perfect. Many of the problems that code was intended to solve such as UV conflicts would have to be replaced with...something. I don't know what it would be.
Intersections are hard, but on the ideal intersection (square, both receiving streets across from each other the same width) you can create a procedural intersection pretty reliably. Manual modeling of intersections should likely be done honestly for a bunch of reasons related to the fact they are becoming increasingly complex entities in reality (Portland Street View has some examples).