Firefly - Light Emitters - Bouncing bouncies...
morkonan last edited by morkonan
OK, so an object with the Emitter attribute is a bounce target for ray-tracing light functions. In some renders, even in Firefly, it's critical to have this enabled for key objects if you want a "realistic" looking render and are trying to approximate a real light simulation in FF. (Yes, I know, it's just a hack for such things.)
But, one issue is that this can add significant render time and, in some cases, the complexity of the geometry for the emitting objects isn't entirely necessary. IOW - Even though the object is fairly complex, all one needs from that bounce is a usably-accurate simulation of the event, itself, not whether or not "face x,y,z" is represented exactly when the light ray hits it.
The Situation: Last night, I tooled around with some exterior render shots with FF using "The Neighbor's Backyard" model/scene from First Bastion. (Picked it up on sale since it reflected a LOT of work that I wasn't willing to do, myself! Highly encourage peeps to be on the lookout for it.)
The issue is that there are a ton of objects in that scene and many of them have a lot of details. But, the light bounces from these details aren't, necessarily, important. So, for instance, a "downspout" or a "water meter" is not going to play a significant part in the overall simulation of light bounces and neither is the gutter geometry or the molding on a door frame, etc.
But, the houses, themselves, will play a dramatic part in the simulation of that light. However, they also have more complex geometry in their group that is relatively insignificant.
The Background Info: "Hitboxes" are common in calculating things like this. I do not know if Poser's path tracing uses hitbox-like simulations in FF. I don't see anywhere that indicates it does and, in my experience, complex emitter targets for IDL always hog processing power. For this reason, the complexity of groups of individual faces, things like Poser Physics use a "hitbox" target for their calcs, since calculating a collision with an individual face, and another, and another, all on the same object is... needless for rather simple simulations of collisions. (All video games use a similar system where warranted.)
Poser is capable of generating geometry and is capable, as Poser Physics shows, of understanding and generating hitboxes. There are also plenty of scripts that generate geometry, many of which can detect object surface features and dimensions.
The Conundrum: Moving through a huge list of complex objects and toggling their attributes is... lots of work. And, even if done with an eye for balance, most objects often have complex additions that don't contribute a lot to the final product, yet Poser will still calculate their effects. This... can take the renderer a bit of time, time/work that is probably more valuable spent doing something else, considering the user's desired render-result.
The Question: Can a script that, with user-input, identifies and constructs a "hitbox" of user-defined complexity be written so that the user can reduce the calculation time for bounces to something that is more manageable, yet still yields a fairly accurate simulation?
ie: Run script -> User identifies objects/figures for hitbox allocation from scene list, set "hitbox complexity" variable per object/group (How closely the hitbox follows/constrains geometry, from simple common "hitbox" to more complex, yet still simple, shape), set if box to be constructed by Group or by entire Figure, for multigroup objects/figures, construct hitboxes, toggle hitboxes invisible in render/camera, toggle on Emitter for hitboxes, toggle off emitter for hitboxed objects/figure groups.... Rinse/Repeat/Clearchanges as necessary....Profit? :)
Edit- Apparently, I'm still ahead of everyone. Free free to ask me what happens to the rest of you in future-time...