[SOLVED] Node::update_world_position()

[Greg.Mildenhall]

Upgrading from 2.3.1 to 2.6.1, we notice that most of the logic that was in Node::flush() has been moved to Node::preRender() but that the update_world_position() call was not brought across. This seems to be the reason why our ObjectTerrain is being culled by 2.6 as if its bounding box were roughly (0,0,0)-(0,0,0) even though we call setHeights() successfully on every surface and all of the bounding boxes/spheres for the terrain node and all of its surfaces look fine.

Adding the update_world_position() into Node::preRender() fixes the problem so perhaps this is just an oversight that you'll patch in the next release, but maybe it was intentional and indicates that we're not using the ObjectTerrain API correctly somehow?

(we do have another codepath where we loadTerrain() from disk that seems fine, but we haven't narrowed down what the difference is - presumably we make another call somewhere in that path that accidently triggers a WorldPosition::update())

[morbid]

Hello Greg,

could you please give us steps to reproduce this behaviour?

[Greg.Mildenhall]

Sorry, I've had a good crack at this and so far couldn't make it happen in a small example. There must be something different about how we initialize the terrain but I can't figure out what it is. :(

I take it that the change removing update_world_position() was a deliberate one and that you weren't expecting it to change behaviour? (Although according to another recent thread, it seems maybe it also had repercussions for ObjectBillboards.)

[silent]

Hi Greg,

There was no changes in ObjectTerrain as far as I remember. A small test scene (or a big one with large terrain) will be a good point to start the investigation. With no reproduction we can't suggest any solution, I'm afraid.

Thanks!

[Greg.Mildenhall]

Yes, that's why I've asked for an explanation rather than a solution!

As I said in my initial post, the change is in Node, not ObjectTerrain. Whoever made the change will at least know whether it was a deliberate change or an accidental one! And if it was a deliberate change they'll have some reasoning why they expect it to be a valid, non-breaking change.

[silent]

Hi Greg,

The thing is that flush() methods were just renamed to preRender() inside the engine sources (almost 1,5 years ago). There was also a small change that could affect this behavior - all the update_world_position() calls were moved to the methods where bound box is calculated.

update_world_position() added into preRender() for ObjectTerrain will not cause any performance drop, so it's the best solution to your issue right now.

I've added this bug to our internal bug tracker.

Thanks!

[Greg.Mildenhall]

OK I finally have a small repro scene. Turn 180 from the initial camera position to face the sun, then tilt the camera up and the terrain will disappear before it reaches the edge of the screen. The effect is more pronounced if you fly over to the far edge away from the bounding box.

I'm not sure exactly why the clutter is necessary to trigger the bug, but I added it to try to complicate the WorldSpatial tree and it seemed to work.

START_FRAME is there to fight a race condition against RENDER_MANAGER_RESOURCE_UPDATE (that code doesn't look right to me??) so you may need some other value.

terrain_00.cpp

[silent]

Hi Greg,

Does update_world_position() copied into preRender() fixing this issue?

[Greg.Mildenhall]

As I said in my initial post, it fixes the particular symptom we're seeing with our Terrain Object. Also, I've given you a repro scene so you could try it. ;)

But from what I've seen, I'm not convinced it fixes the underlying problem (plus if I put it in ObjectTerrain rather than Node, the problem could still affect other types of Node) and from what you've said in the recent ObjectBillboards thread, it doesn't match your intended usage of update_world_position() so it's likely to be at odds with the eventual fix you guys come up with. Obviously we'd rather have as few patches as possible that don't match the base, especially if they look like they could mask other problems with the way we're using the API.

But given your timeframe for 2.7, I expect this will be your interim fix? In that case we're OK with patching our 2.6 in the same way.

[Greg.Mildenhall]

Can you confirm that adding an update_world_position() call to ObjectTerrain::preRender() is the fix you're going to go with for 2.7? Then we can finalise our own decision to patch it that way for our approaching 2.6-based release.

[silent]

Hi Greg,

Quote

Can you confirm that adding an update_world_position() call to ObjectTerrain::preRender() is the fix you're going to go with for 2.7?

Yep, that's the fix that we already implemented and it will be available in 2.7.

Thanks!