Hmm.. it doesn't look bad actually. Remains to be seen how much repairing work is required, but could prove a viable solution for the working base ? Sent from my phone using Tapatalk
That's the plan, it has some serious limitations, but for the base, it's awesome. The repairing is some vertices that need to be re-welded, some mapping that needs to be tweaked and the obvious one is the non existing shading groups.. curbs look pretty rough.
before you jump to max, you should create a border transition edge from tarmac to grass. if you havnt already done so of course.
Is there a way to control width or height of string objects? The tree wall... I used a wall object then reassigned a tree material to it, but say I wanted it taller or shorter, am I stuck with it till max? Same with rumble strips, I need thin them up in some corners... didn't see an option that allows for that
Can't say this enough... RTB is an insanely powerful tool! It does have flaws, like poor vertice normal control... but passing it through MAX for some cleaning up and the right shaders, a very photorealistic environment can be achieved!
This looks very nice indeed. But in the end it will still be about how much time you have spent. Enduser will never know what tool you have used. This sounds like a workflow I am seeing best also: lay the foundation in RTB and do the rest in 3d package. Sent from my phone using Tapatalk
Hey guys, maybe this is of interest to you. I am currently working on a workaround that will provide RTB with alternative elevation data and terrain textures. For many regions, Google unfortunately provides poorly resolved images and very rough elevation data. On the other hand, there are many regional mapping services that provide much more detailed data. This data can often be accessed from WMS servers. And that's what I do. I have a web server running on my computer. The URL maps.google.com which requests RTB is redirected to localhost. Because RTB communicates with Google via HTTPS, I had to generate a self-signed SSL certificate for the address maps.google.com on my server and import it into the Windows Certificate Store as a trusted root certificate authority. With PHP scripts I intercept the requests RTB makes to Google and convert them so that a regional WMS server provides me with the appropriate answers. I convert the output back to Google format, so that RTB understands it. And the greatest thing is - it works! Some things are not quite right yet. For example, At the highest level of detail, the terrain is currently a little fissured. And the biggest disadvantage is that the WMS server doesn't deliver as fast as Google does. If you start a new project in RTB and request "Google", it can take up to an hour. An advantage is that I save the requested map tiles. So you can later manually assemble them to a high resolution terrain texture, which makes laying roads easier. If all this goes well, I will write a manual for interested people and provide the scripts. But keep in mind that this is not a one-click solution and the setup is a bit more demanding. It will certainly not be a solution that works instantly with any WMS server. Some knowledge of PHP will be required.
Wow, very big difference in results. But most importantly a very clever workaround ! Thank you for sharing, will be very curious to learn how this works. Cool stuff. Sent from my phone using Tapatalk
wow " very interesting imo ". recently I had thought about the old zaxon method and btb and what could be viable with rtb and some external injection. it`ll be interesting to see how the road generation algorithm's works around this...
Am I right in assuming that this road generation algorithm has something to do with KML? RTB need to support the import of KML for that. Currently RTB only queries static map and elevation via the Google API.
yeah, the road generation over the underlying terrain is RTB`s own. Brendon did mention using an API for roads. but presently it has no connection. just the terrain capture functionality with google. what about injecting lidar into the system ? please look into that man
I have no idea in what form lidar data is available. But in the end, it's probably a collection of XYZ coordinates. You only have to store this data in a database, which can be queried with PHP. Basically not a very big problem. The elevation data I am currently using from the WMS server are also laser-scanned and are available in a resolution of 2 meters. The biggest limitation will probably be the terrain resolution of RTB. I guess the smallest triangles have an edge length of 1-2 meters.
I'm reading about 50 cm triangle edge length on the scenery at its minimum when selecting or switching to non google terrain tools and sub dividing. lidar comes in various point cloud forms, I use a program called cloud compare to convert it to a mesh in my case a standard fbx file the blender file used is STL I believe. another idea I always had was possibility of generating a flat mesh in RTB. exporting. conforming it to the lidar vertically and re importing it back into rtb somehow.....
Aha, I didn't even notice that non google terrain can do smaller triangles. But anyway, injecting is only possible with google terrain. And for re-importing, native RTB support via FBX or XPack is still needed.
The format varies. Sometimes only a list of Z values at a know grid spacing. But, if the user pre-formats the LIDAR data into google format then I guess, your method would just pick it straight up.
