openSimEarth gets statics, and goes back to decal roads.

[chriscalef]

Hey there, just a quick update on the recent progress...

First off, the next major world building component is now in place: in addition to terrain, forests, and roads, we can now place TSStatic objects with the World Editor, save them to the database, and page back through them at will.

http://opensimearth.com/images/screenshots/statics_01.jpg

As you can see, I didn't do much with this godlike ability yet, because that devolves quickly into countless hours of art time, but in this image the Zero (from flightgear, textures still broken) and the wharf and industrial shacks (many thanks to 3TD Studios for the free art!) are placed using this method. Note that scale also works, as demonstrated by the taller building in the background.

The other big news is, thanks to a most helpful comment from @JeffR on my last blog, we are now able to return to DecalRoads instead of MeshRoads, due to the containsPoint() function. In addition to being much more efficient, in this way we also are able to get rid of the absolutely unusable Z fighting which always seems to follow my MeshRoads around, possibly due to float error from being too far from the origin (running around six or seven thousand meters out here).

However, I'm still having major problems with raycasts at the edge of the terrains. Here is an older image with MeshRoads and trees, demonstrating my problem:

http://opensimearth.com/images/screenshots/road_09.jpg

As you can see, reported heights become wildly inaccurate at the terrain edges. Which actually makes for some pretty amusing bugs on the mesh roads, but hardly desirable. Lacking the time to really dig into this, I've been simply avoiding putting trees close to the terrain edges, and I fear I will have to do the same thing with roads, for now. While mesh roads show the problem as seen above, with decal roads the symptoms are different - from one side, but not the other side, of the divide, any decal road crossing from one terrain to another will shoot vertically up in the air, not infinitely but for quite a distance:

http://opensimearth.com/images/screenshots/road_14.jpg

Since this whole world is meant to be more for fun and experimentation than for a perfect simulation at this point, I think I'm just going to work with what I have and create a little DMZ style "no man's land" between each terrain tile. Eventually I plan to move this to T6, and/or fix the problem here, but other parts of the project are calling my time harder than this. If anyone has any ideas, I'd love to hear them though!

As a final note, this might be a good time to mention: openSimEarth needs art! If anyone out there in Torque world has public domain artwork, or private models they'd be willing to share, including trees and other vegetation, animals, houses, industrial buildings, and/or anything else you think would fit in, please consider contacting me, I'd love to give you credit and include some of your work!

So anyway, that's where we are for now...

[JeffR]

I'd seen a few other people comment about casts and stuff breaking down on terrain edges, but hadn't had much luck with replication. I take it it happens with every block seam?

[chriscalef]

Yeah, this has been regular as clockwork for me. It's interesting because the heights go crazy, but only within somewhat reasonable limits, they definitely don't go completely NaN0 on me. I'm also not at all sure that the problem with the decal roads is exactly the same problem as what I'm getting with the mesh roads and trees.

For the forests and mesh roads height values are being set through a server container castRay. I'm suspicious about whether it could be trying to interpolate heights to the other edge of the same terrain tile. (Will have to test it on flat terrain.) I know through earlier help from Andy Wright that a similar problem is what causes the dark shading on many terrain edges - it is more prominent on tiles with a larger height difference between opposite edges.

The decal roads seem a little different. Observed behavior is they pretty much all stick up to the same maximum height when a road goes completely across a terrain border, but a very interesting lesser effect was noted: when you move a road gradually across a terrain border in the road editor, the edge of the road sticks straight up at the terrain edge, and goes higher as you bring it farther over the border. It would seem that the road decals can't figure out how to cross from one terrain to another.

Also interesting was that the decal road behavior is only visible from one side of the border, from the other side it looks fine. :? One sided polygons?

Anyhow, I'll poke around on it but I don't think it's going to be my highest priority at the moment. And who knows, it sounds like @andrewmac has a terrain engine that's running laps around this one, so maybe I'll just have to try dropping all this into there pretty soon...

[Azaezel]

Would https://github.com/GarageGames/Torque3D/pull/565 help, you think?

[chriscalef]

OMG, that looks like an _extremely_ helpful PR, yes, thank you Az. I'll be sure to profile some of those disputed methodologies in there while I'm at it. :-)

[JeffR]

Yeah, I did pull that to test, there was some issue with the terrain texture fix they added, so I'll try and get that sorted out and we can get it merged in.

As for the edge issue, I did create a new map with 2 terrains side by side, both flat, and plunked the cheeta right on the seam, and all 4 wheels correctly matched to the ground(which uses raycasts)

So the best-guess so far is that - going off your mention it seems to be a problem when the opposite sides of the terrain block have differeing heights - the terrain is trying to have wrapping occur, even if that setting is off. If that's the case, that should narrow things down quite a bit.

[chriscalef]

Yup, sure enough, I tested it in a place with less height difference, and the problem is much reduced. This is kind of a messy screenshot because of the road interference, but here you can see the trees right in front of the camera only slightly higher than their neighbors, while the trees going off to the left, with a major height difference, are much higher. Bingo.

http://opensimearth.com/images/screenshots/forests_06.jpg

[JackStone]

This project looks amazing! It is quite similiar to my current main project, which is to create a kind of "Sandbox Universe". I am not creating a flight simulator or a representation of the real life earth, it's more of an artificial life/simulated reality project.

The challenged you are facing will be very similiar to what I will be facing, I suspect, particularly the paging terrain.

Is your terrain spherical, like mine is/will be? Or is it a very large "flat" terrain?

[chriscalef]

Good lord, how time flies! Sorry I somehow missed your comment from MONTHS ago, @JackStone, but thanks!

To answer your question, my terrain doesn't deal with the earth as a sphere, except in the sense of getting data that comes from the spherical earth... ie, since I'm focused on primarily a first person view, with some perhaps generally low elevation flying, I'm only planning to load a reasonable amount of 3D terrain at a time, not enough to justify messing around with the slight curvature that would be present at this scale. If you were to keep walking, you would eventually loop around (assuming the game didn't crash before you got there, lol) but at any given place, the heightfields are assumed to be coplanar.

Good luck with your project, look forward to hearing more about it!

[JackStone]

Thanks a lot for that explanation, your project is very interesting!

[HeadClot]

Hey Chris -

With the upcoming 4.0 update would it be possible to add terrain paging and possibly world origin offsetting into the main T3D Branch?

Just curious,

HeadClot

[chriscalef]

Sure, if there's interest I'd love to help facilitate that! Would look forward to a good round of code review on my current implementation. In particular, threading of terrain loads would be a *massive* improvement.

[chriscalef]

Also, I suppose I'd have to cook up an XML based storage system for forest, street, and item data, to replace sqlite.

[JeffR]

Well, I had some ponderations I've put a fair bit of brainstorming towards in regards to loading large levels in my one workblog post here

As someone that's actually crunched on the issue, I'd be 100% keen on your feedback on the idea.

[Azaezel]

As an aside, since you're taking decalRoad specifically, would you happen to have an equivalent to https://github.com/GarageGames/Torque3D/pull/1457 laying around? Tried my hand at it and struck out on getting the detection to show up right. (Believe that'd be the last bit of that that would need hooking up prior to any RnD/serious discussion on per-material effects and the like.)

[HeadClot]

Sure, if there's interest I'd love to help facilitate that! Would look forward to a good round of code review on my current implementation. In particular, threading of terrain loads would be a *massive* improvement.

 

There is great interest from me at the very least. Get in touch if you need help testing. I am no programmer but I am an artist.

Q. Does your current large world implementation work in multiplayer?

[TorqueFan]

Also, I suppose I'd have to cook up an XML based storage system for forest, street, and item data, to replace sqlite.

 

I've been using Torque's SimXMLDocument class extensively for quite some time. Once I tried it out awhile and pinned down exactly how to store/retrieve data, I started using it exclusively for data persistence.

You can use code or script. You can index data and iterate said index. For multiplayer this adds a layer of security, as all .xml files are accessed exclusively through your custom script/code functions.

Feels like a win/win.

I hadn't profiled it(yet) to see how much of an impact it may have on server performance with the reads/writes. But then again, thus far the amount of data has been so minimal that it doesn't matter regardless. As things expand, though, will have to keep an eye on all the SimXMLDocuments being read/written and probably use a manager class to handle read/write requests. Just thinking out loud, but yea, SimXMLDocument has been working pretty well for me as a way to store data.

[chriscalef]

Q. Does your current large world implementation work in multiplayer?

 

To the best of my knowledge, yeah. It's just a paging system for terrain grids, so as long as both clients have the same terrains they should be able to interact normally.