VPR and SpatialQuery

[dpont]

Hi,

Question about SpatialQuery, shading context,
QueryID is acquired in create() (released in destroy)
a raycast is filled in evaluate()
all existing items (numitems and item) are updated in newtime()
this works with normal render,
updating items for SpatialQ is even not necessary if I just move objects.

How could this work properly with VPR?
vpr with raycast crashes here when moving objects
(without update function or with update and using 'limbo states')


Denis.

 

[Sensei]

Just a thought: what are you returning from Node useItems() to LW?

Like I said earlier: I would try to aquire() just before starting rendering/previewing, and release() right after rendering/previewing. e.g. VPR is stopped, SpatialQuery data are released ASAP.

 

[dpont]

Not sure that useItem() is relevant for this,
I'm experimenting a simple situation, not changing references,
so everything is simple and stable in my sample scene.
I wrote about the SpacialG functions for counting and enumerating
its items, this is only important for updating, which is not the question
for isolating unstability of VPR here.

In the example of Boolean node it worked normally with normal render
and VPR, moving the objects or camera ,when I used my own raycasting,
raycasting of SpatialQ is of course different on this side.

I remember also that SpacialQ was only available for displacement at the beginning,
so I would know if there's some thing to know not revealed in the doc.

I'm using acquiring and releasing the queryID like advised in the doc,
this is safe for normal rendering,
does somebody knowing some other specificity of VPR?




Denis.

 

[dpont]

I tested the "QueryID" (from create()) and it seems to be not valid
for VPR sometimes, I'm able to go further with it while moving the object
if I try to "re-acquire QueryID" when it is NULL, but still crashes.

Denis.

 

[Sensei]

IMHO, such resources should be get prior rendering (node->init()), and freed after rendering (node->cleanup()) (or alternative way of detection of rendering state).
Not node->create(), and node->destroy().

 

[dpont]

IMHO, such resources should be get prior rendering (node->init()), and freed after rendering (node->cleanup()) (or alternative way of detection of rendering state).
Not node->create(), and node->destroy().

Unfortunatly no, I tried it, this is even worst,
I guess that touching the QueryID in this area is not safe
because init/newtime/cleanup is multithreaded for VPR,
also limbo state is not helping here.

Denis.

 

[dpont]

Just to add that I speak about an issue for object moved at realtime with VPR,
keyed animation works well.


Denis.

 

[dpont]

Ok, this issue is fixed in LW 2019.
No problem for realtime moving in VPR while raycasting.

However there's a new issue from raycasting in LW 2019 spacialquery,
with double-sided surface (here in boolean node),

In LW 2018:


In LW 2019:





Denis.