Cross Page PRP Referenes cause Sorting Order Issues.

[Traveler263]

Under still uncertain trigger conditions (As Descent was loading perfectly in spite of these apparent systematic issues for several iterations, and the bug cropped up suddenly after a cross page reference appeared to try to load an item from a PRP I had not pushed to Minkata for testing- but I am NOT certain that was the trigger cause of the problem), it seems that having too many Cross-Page references for a mesh parent being in One PRP, with its drawable child being in a different PRP can have knockon effects on all other objects within that PRP, causing irregular and inconsistent loading.

For example, in this image, one log amongst this ladder was erroneously still assigned to "dsntVolcano" PRP which had a drawable object within it as the child of a Parented object in a different PRP, resulting in many items from the "dsntVolcano" PRP to load incorrectly.

Bizarrely, this could also cause items in "dsntVolcano" PRP to Partially render correctly- for example the following objects, which were having random parts of single meshes rendering correctly while the rest of it was not.

Per Ehren on discord:

For the caldera. The dsntUpperShaft page had an object that requested a child object that had been accidentally sorted to the dsntVolcano page, this caused the Draw span to be entirely loaded just by the request for the one object that had now been added to that wrong Draw span by virtue of being sorted to the wrong page.

The issue seems to be a conflict caused by the loading of the Draw span from both the parent object's page and the child object's page itself (which carries important coordinate data for where things should actually be displayed).

Additionally to this, adding to the weirdness, there seems to be a location-dependent trigger on where one links FROM with regards to rendering the age correctly or not.

During testing, it was noticed that if one linked to Descent either by linking book or python command, the location one linked FROM was highly dependent on how things loaded correctly.

If one linked from the relto bookshelf to Descent, either the treasurebookshaftfall spawn or the default link point either by book or command, the age would load with many drawn items loaded in incorrect places. HOWEVER, if one stood at the terminal in the Nexus age, as if one had just used it, and was either using the nexus itself or a console command, the age would load its visuals successfully. YET- if one took several steps away from the machine and linked with a command, the age would not load its visuals successfully.

To help illustrate this issue, I have an imported relto mesh paged into a copy of my descent blend- the fissure hole approximating the successful nexus link, and the hole where the hut is approximating a failed link from relto.

During testing, I migrated the default spawn point to the same location as the treasurebookshaftfall link point to ensure that the destination point's physical location was not a problem.

(The green line approximates where the successful link was originating from, the red line approximates where a failed link was originating from.)

Links originating at the Relto Fissure area (Where the Nexus is, roughly at the Zero Point of the Descent File, essentially) seemed to work successfully if you were in the exact tiny space that the nexus linkout point is, but otherwise was such a significantly tiny window of physical space that it's a miracle this was even stumbled upon in the first place.

My suspicion is that when items from the dsntVolcano PRP were improperly being loaded, they were being loaded with 'local coordinates' for a parent-child relationship which were being read as global coordinates, rather than their true global coordinates. This would lead to, in cases where one loaded the calling-upon PRP to another age, visuals such as this:

(Picture courtesy of Ehren)

In this example, Ehren paged in "dsntUpperShaft" PRP to Relto, loading all of its called upon drawable spans- this included our missing Caldera Objects from the dsntVolcano PRP that were NOT assigned to this PRP, but were accidentally being called to it due to a parent object reference from dsntUpperShaft to its child object in dsntVolcano.

The local coordinates for the drawn objects were applied instead of their local coordinates, resulting in this updside down Caldera view.

My own personal suggestion would be to institute some kind of check for "Is a Parent Object and its Child Object in the same PRP?" and halt an export if that is the case- listing said parent object and child object as being in mismatching PRPs.

[Hoikas]

When you have a chance, can you please assemble a minimum viable reproduction (MVR) of this issue? An MVR is a blend file that I can click export and see the issue almost immediately on link in with a minimum number of steps. The MVR blend should contain the smallest number of objects, pages, and textures as possible to display just the issue at hand.

[Traveler263]

ill try to build up a MVR, but if it helps any, I also have a version of Descent from before I corrected the inter-page issues. I'll paste a link to that here while I try to create a MVR, because, I have no idea how BIG an age needs to be before this cross page parent-child problem becomes something the game engine has a problem with. And I'm still not sure if it's repeatable on HURU either.

https://drive.google.com/file/d/1z8guuE32nm_0qauAdgIQ-gKV-Lff7RXs/view?usp=drive_link (Bugged Descent Build: The viewpoint in editor is focused on the object we determined was causing all the misrendering of the caldera- the child object "CRASHDEBRIS" from PRP dsntVolcano, which was parented to an object in dsntUpperShaft.}

[EhrenCG]

Okay, so from my experimenting, H'uru does NOT have an issue showing ages with these drawable child objects.

However, I would argue that this is still something fundamentally wrong for the PRP code to have, even if a client can be designed to handle the nonsense better.

Even on H'uru, when I would page in dsntUpperShaft alone, without the rest of the Descent age, I still got the dsntVolcano page loaded in with it, and with stuff in the wrong place, since it only got the draw span from dsntVolcano not the rest of it loaded in. Meaning this issue could lead age creators to have pages dependent on each other that they didn't know were. And make general organization harder.

At any rate, if you want to test if this issue exists using H'uru, you need to check if paging something in causes another page's stuff to also load in. Rather than just linking to the entire age.

[Hoikas]

However, I would argue that this is still something fundamentally wrong for the PRP code to have, even if a client can be designed to handle the nonsense better.

I think this is a far statement. Korman shouldn't be generating PRPs that don't make sense.

For a simple-ish test Age, I think what I would do would be to isolate one specific case of an object tree with cross page dependencies. Make an Age with a flat plane floor, link in point and nothing else. There's you default page. Bring in the object tree with cross page dependencies. Just those objects - no others. Put it in the floor plane where it can be seen easily. So we have a floor in default that's always there, then the other pages can be turned off and paged in individually for a test.

[Traveler263]

For a simple-ish test Age, I think what I would do would be to isolate one specific case of an object tree with cross page dependencies. Make an Age with a flat plane floor, link in point and nothing else. There's you default page. Bring in the object tree with cross page dependencies. Just those objects - no others. Put it in the floor plane where it can be seen easily. So we have a floor in default that's always there, then the other pages can be turned off and paged in individually for a test.

I think I understand what you're after here, but just to clarify:

A Platform over the Zero Point of the age, and then... bring in the bugged objects from the bugged descent build, or recreate it manually with original bespoke objects?

[Hoikas]

I would be tempted to try bringing in the objects we know are bugged.

[Traveler263]

okay, so ill attempt to just bring over the parent and child objects i know caused an issue- HOWEVER- one followup question:

Do I leave behind ANY other objects that might follow the append from the descent build when I drag over JUST those objects, or cull anything that isnt the required objs?

EDIT: that is to say, sometimes Blender imports more objects than JUST the ones I select. do i leave those linked objects alone?

[Hoikas]

Good question, and I'm not actually sure what the best answer is. On one hand, I don't want there to be a lot of digression from the known bugged state. OTOH, we don't want to deal with a lot of extra crap. I'm leaning slightly toward saying blow away anything that isn't the objects you tell blender to import.

[Traveler263]

I'll do two copies for compentcys sake. One with all the assorted fluff and one without.

[Traveler263]

it seems i may not need to do two copies of it. after importing the two objects, the only additional thing that got appended this time was just the vis region mesh, and I've had wonders if that wasn't also part of the problem so I'll leave it in and I'll center it over the zero point.

https://drive.google.com/file/d/1lVtdlGCdGcypfR3BcIPIri4wP6AZG0qk/view?usp=drive_link

Here's the link, let me know if it's not downloadable for any reason.

EDIT: if this doesn't prove useful for tracking down the issue, i'll leave the busted SpinNodes2 Blend link active earlier in the thread just incase you need to dig deeper into it.