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
