It appears that geometry can somehow be “temporarily missing” while rendering a heavy scene during manipulation. This happens in Iray, but also in Cycles. Here is what it looks like with Cycles (Scene is an Array 25x25 of standard spheres, being moved in gumball mode).
So you are moving the entire array?
I just tested Raytraced with CPU, since it seems that my card can’t handle the large scene when manipulating it - just starting the Raytraced mode with a 25x25 sphere array scene makes Rhino take around 5.8GB of RAM. With CPU as render device I don’t see geometry going missing, but one guess is that the data doesn’t fit in GPU RAM. Not sure how well defined behavior is when GPU RAM is maxed out, but perhaps that could explain missing geometry.
I’m still not doing anything smart with the geometry yet for Raytraced, bugs and materials have kept me from working on the geometry handling part related to my Aggregaton branch (aggregating mesh data into fewer objects).
Yes, all spheres are selected.
I am on a K5000. Note that if you let it render (at least in Iray), all the geometry eventually returns. It is just an intermediate stage. It “feels” like we don’t get all the update calls, or something like that.
What happens if, say, 50 spheres get updated, and then a new camera move comes in?
That entirely depends on your implementation, but probably best is to ensure your data gets to the end of the syncing before handling new updates. Raytraced doesn’t do that yet very well, but my plan is to add an additional queue-like solution to Raytraced to handle that scenario. This isn’t part of the ChangeQueue mind you.
Actually, the better thing to do here would be to set some flag for the duration of the data syncing before calling the next flush on the ChangeQueue.
/Nathan
Wouldn’t this effectively reduce our speed, since we would avoid handling the next frame until all is pushed?
In any case, I do not think this is the reason. If you recall, we actually call Flush() in the NotifyEndUpdates() call (and only there), and so all update calls should be done.
Edit: Ack, I am again falling for thinking that NotifyEndUpdates() comes after Apply change calls. Need to think more about this. Which brings me to a question:
How do we know that all Apply calls have been completed?
Question: you mention setting a flag until data syncing is done, but how do we know when it is done?
I meant a flag for your own syncing part. I assumed you do this in a thread of your own, so you’d have to wait with handling the next notification of update end by the change queue. So you should know whenever your upload code is done.
/Nathan
I am not sure I understand right yet.
We sync our data in the ApplyChange calls. NotifyEndUpdates is called before the ApplyChange calls, IIUC, but how do we know when there are no more Apply*Change calls coming? We need to know when there are no more coming, to decide whether or not to allow the Flush call, right?
@CarstenW, do you have separate threads for listening to NotifyEndUpdates() and calling the Flush()? If so then you probably need to guard that.
We call Flush from NotifyEndUpdates.
This fixed some small issues we had.
@CarstenW We’re going to need to be able to repeat this here - can we get a working version of the V6 iRay plug-in so we can figure out what is going on?