I can't comment on the particle system in 6.3, but I can give some background info on the base system:
The Render base class attempts to correlate GeoInfos between two separate time-sliced GeometryLists by using the GeoInfo::out_id() hash, but as I recall it does nothing to correlate individual Primitives inside each respective GeoInfo. If I recall there may be a test for point counts to make sure that they haven't changed between time slices. In Renderman you have to declare whether a Primitive can motion blur at the moment you submit it which creates an obvious correlation, but I didn't make a similar mechanism for Nuke's geometry system. Without that declaration it's hard to uniquely identify a Primitive from time-slice to time-slice without stamping every Primitive with a uuid like the GeoInfo has. In hind sight that's probably a more robust approach, or completely alter the way the time sampling happens in the GeoOp stream to eliminate the complete separation of time slices. The out_id() approach grew out of adding motion-blur support fairly late. It ain't Renderman....sorry. -jonathan On Jun 18, 2011, at 10:37 AM, Moritz Moeller wrote: > I ran into this issue with particles and the special case of > multi-texturing. > > Let say I have an GeoInfo with particles in it. I use multi-texturing on > this via the ParticleEmitter node's 'particle' input. > > The issue is with motion blur. For simplicity, I stick with the two time > sample case, one at shutter open (time0), the other at shutter close > (time1). > > So a non-multi-textured particle system with 4 particles (emission rate > 4) looks sth. like this at frame 1: > > GeometryList[0]: > "id" @ time0: 0 1 2 3 > "id" @ time1: 0 1 2 3 4 5 > > Why there are already 2 additional particles at time1 I don't quite get. > At an emission rate of 4 (no rate variation) it should either be 4 > additional ones or none (assuming time1<frame). > But lets ignore this for now. > > Now what happens in the multi-texturing case, internally, is that the > single GeoInfo is split into n GeoInfos, one for each material instance. > > In the example case, in frame 1, since emission is set to 4, 4 GeoInfos > are created, each containing 1-2 particles. This is all fine. > > When ScanlineRender has rendered a frame and I switch to my own > renderer, accessing the same geo data, I get this ordering: > > GeometryList[0]: > id" @ time0: 0 > id" @ time0: 0 > > GeometryList[1]: > id" @ time0: 1 > id" @ time0: 1 > > GeometryList[2]: > id" @ time0: 2 > id" @ time0: 2 > > GeometryList[3]: > id" @ time0: 3 > id" @ time0: 3 4 > > This is exactly what I expect! Perfect. If I the switch to my renderer, > all is dandy. Great! > Note that particle with "id" 5 at time1 has disappeared. Again, lets > ignore this, I thought i worth mentioning though. > > However if my node is the one querying the particle system 1st, w/o ever > using ScanlineRender before, I get this ordering: > > GeometryList[0]: > id" @ time0: 3 > id" @ time0: 3 4 > > GeometryList[1]: > id" @ time0: 1 > id" @ time0: 2 <-- wtf? > > GeometryList[2]: > id" @ time0: 2 > id" @ time0: 0 <-- wtf? > > GeometryList[3]: > id" @ time0: 0 > id" @ time0: 5 <-- wtf? > > > So the 1st thing that one sees is that there is no particle with "id" 1 > at time1 any more. It has simply disappeared. > There is also a particle with id 5 now which was in the original time1 > sample in the non multi-texturing case, but was omitted when > ScanlineRender had requested the geo. I mentioned this above. > > As you can see, the GeoInfo at GeometryList[1], GeometryList[1] & > GeometryList[3] has non-matching "id"s resp. > This gets worse when emission rate is bigger, I basically get almost all > IDs not matching. And the position etc is also not matching, Meaning > indeed, the particle in GeometryList[2]@time0 is the 1st sample of the > particles in GeometryList[1]@time1! > > And this goes on. To get the correct position for the one particle in > GeometryList[2] at time1, I need to grab GeometryList[3] at time1! > > For GeometryList[1], I am out of luck, the particle with "id" 1 has > disappeared at time1. > > In other words, to work around this, I'd have to merge all particle > GeoInfos in my whole Scene into one massive particle object before I can > correctly send them to my renderer, after untangling by "id". > > But since ScanlineRender manages to get them in order, I'd rather avoid > this. :) > > This smells like a logic bug inside Nuke that is triggered by a > particular call chain of accessing Geo. > > When ScanlineRender does the access, the bug is not triggered so when my > renderer accesses it afterwards, I get a cached version of the geo and > all is dandy. When the geo is requested by my node 1st, the bug is > triggered. > > Any suggestions? > > > .mm > > > _______________________________________________ > Nuke-dev mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev _______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
