HOW TO IMPROVE LIGHTWAVE: Rendering in Passes

[MooseDog]

very! timely idea roberto, thx!

with the announced death of the only available plug-in for this, i'm supposing ideas will follow along the author's concept: multiple scene generation from within one scene, all batch rendered, and then composited. definetly! a great idea for newtek to explore (if they have time and money:) ) (which is not to say there are other concepts out there).

[jeremyhardin]

In order for rendering in passes to be properly implemented, a new heirarchial system of parameters needs to be implemented. By 'parameters' I mean everything from translation to surface properties. If the higher grouping structure doesn't have a specification on a parameter, the item defaults to the next highest specification. (i.e. if none of the heirarchies specify a different color, the item's individual parameter for color is used).

So you've got individual parameters.
Then Group parameters (which override individual parameters).
Then Layer parameters (which override group parameters).
Then Partition parameters (which override layer parameters).
Then Pass parameters (which override scene level parameters).

So your scene file contains one pass with one partition, one layer, and no groups by default. Group and Layer parameters are intended to extend across the scene. But partition parameters are unique to passes. In other words, if an object is going to be visible in one pass but hidden in another, it would need it's own partition to hide/show it for that pass.

You should then be able to add unlimited passes within that one scene. Each pass would have it's own render time and rendered output, so Ambocc passes and Foreground, Background, Depth, Character matte passes could all be contained in one scene file. Within the passes you could override surface properties to be only diffuse or only specular. You could override scene level items like light position or alter animation on a per-pass basis (by animating translation override).

Then include the option to output as many of the channel buffers as you like as well. So you don't have to have 20-30 individual scene files for one scene. If the camera moves, you're not forced to update 20-30 pass scene files. It's one file. It still renders each pass individually, but it's a lot more organized and bearable.

[Cageman]

So you don't have to have 20-30 individual scene files for one scene.

Nice suggestions!

Here are some of mine:

1. A global surface setting which overrides the surfaces of the objects selected. This setting is saved with the scenefile. No more need to save out new objects when setting up Ambient occlusion-pass or changing the alpha to shadow density.

2. A reference system. Even though you may be able to get alot of stuff out the door from within the same scene, there are always occasions when you need to create a special pass. You may end up with 2-5 extra scenes depending on what you do. I want to be able to open 1 scene, change the setting and then it will automaticly update in all other scenes which are referenced from this main scene.

3. NT buys the code from Surpasses-developer and integrate it into LW. ;)

[jeremyhardin]

I agree with yours too (with the exception of number 3). :D
1. A global surface setting which overrides the surfaces of the objects selected. This setting is saved with the scenefile. No more need to save out new objects when setting up Ambient occlusion-pass or changing the alpha to shadow density.
For your #1 though, do keep in mind though that if my suggestion were implemented, the objects selected coud be placed into their own partition for an Ambocc pass (called ambocc_objects or whatever). then, the partition could have a surface override that resurfaces only the objects in the ambocc_objects partition in the Ambocc pass of the same scene. So no new object saving is necessary. Same with shadow density. You could clone the Ambocc pass, rename it Castshad, then create partitions with objects casting shadows and objects receiving shadows. The casting shadows partition could have matte object overrides or be hidden to rays; the receiving shadows partition could be resurfaced to have their alpha density be controlled by the shadow buffer. Again, no new objects saved, each pass would have it's own rendered output, and all in one scene file.
2. A reference system. Even though you may be able to get alot of stuff out the door from within the same scene, there are always occasions when you need to create a special pass. You may end up with 2-5 extra scenes depending on what you do. I want to be able to open 1 scene, change the setting and then it will automaticly update in all other scenes which are referenced from this main scene.
Agreed. I implemented some very poor referencing in some of my lscripts (http://jeremy.lwidof.net/lscript), but I would like to see it truely implemented.
3. NT buys the code from Surpasses-developer and integrate it into LW. ;)The only reason I don't personally care for this one is that it's final solution is the output of multiple scene files. Seems a bit slow and backwards to me compared to what it could be. Though if it were made to work stably (and scriptably) and cross-platform, I'd take what I could get.

[Cageman]

I agree with yours too (with the exception of number 3). :D LOL.. :)


For your #1 though, do keep in mind though that if my suggestion were implemented, the objects selected coud be placed into their own partition for an Ambocc pass (called ambocc_objects or whatever). then, the partition could have a surface override that resurfaces only the objects in the ambocc_objects partition in the Ambocc pass of the same scene. So no new object saving is necessary. Same with shadow density. You could clone the Ambocc pass, rename it Castshad, then create partitions with objects casting shadows and objects receiving shadows. The casting shadows partition could have matte object overrides or be hidden to rays; the receiving shadows partition could be resurfaced to have their alpha density be controlled by the shadow buffer. Again, no new objects saved, each pass would have it's own rendered output, and all in one scene file.

It would be very cool, but I wonder how all those network-renderers would handle that? If I submit my scene to Muster (I'm most familiar with Muster), that would mean I have this single scene file so if I have to re-render some of the passes, how would that be? Of course, those applications may need to be uptdated so that each pass looks like it has it's own scene-file, but in truth they are all from the same scenefile. But, yeah... have to agree that your suggestion is a very integrated one.


Agreed. I implemented some very poor referencing in some of my lscripts (http://jeremy.lwidof.net/lscript), but I would like to see it truely implemented.

Yeah.. I tried the camera-reference scripts but they messed up my scenes pretty bad. Had to open the scenefile in wordpad and remove the master plugin in order to be able to open the scene in LW. I never came around to report this error to you. Maybe I should do some more tests with it to see if I did something wrong... :)

EDIT: Just remembered now.. I got it to work, but the animated camera always started from origo in the scene where the camera is referenced into.


The only reason I don't personally care for this one is that it's final solution is the output of multiple scene files. Seems a bit slow and backwards to me compared to what it could be. Though if it were made to work stably (and scriptably) and cross-platform, I'd take what I could get.

I can live with 100 scenes IF a reference system would allow me to change things in one scene and all the others gets updated. Hell, even the Surpasses way of baking out new scenes is somewhat doable compared to what we have now. :)

But your idea is very strong and looks thought out. :thumbsup: I hope the new structure of LW can allow for such thing to happen.

[faulknermano]

In order for rendering in passes to be properly implemented, a new heirarchial system of parameters needs to be implemented.

if LW's dev road does not integrate surfaces in scene files, the route that worley's G2 is probably the best way to go about it. i've seen users do on-the-fly surface modifications using G2's master (through pixel filter). if this is was enhanced and expanded to account for groupings of surfaces, etc etc, this could easily be, given the current LW architecture, one way to control a pass via surfaces.

it goes without saying, for me, that i prefer a pass system that jeremy describes: multiple outputs in one scene file.

also, i think i should repeat this again from the newtek forums. i think a camera should be able to exclude objects from itself. if we imagine the camera as an output, a camera could treat one object as a matte object, while the other camera treats it as full-shaded. this is just thinking from the pov of the current LW system and the idea of how light excludes objects and viceversa. maybe a camera's interpetation of objects is easier / faster to implement right now, and is not necessarily a bad step. if it was implemented, then the "pass-cameras" can be compressed into one camera (having one unified settings), but its output and exclusion parameters broken down into user-definable ones. basically it's like what jeremy is saying, but in closer in current LW terms.

A reference system.

i've successfully used Maya2LW2's reference system for cameras. it works pretty well and updates on the fly. of course, it's optimised for Maya to LW coordination. but LW to LW is still possible.

however, without a doubt, LW really needs a SCENE reference system (we already have object referencing). not only does it double for render passes, but everything as well: particles, hypervoxels.... etc. there are too many examples why a reference system is needed.

1. A global surface setting which overrides the surfaces of the objects selected.

again, G2 does this in a limited fashion. i think currently, it can be done with the existing SDK... unless there are gotchas somewhere there, like limitations as to what can be overriden or not. ;)


It would be very cool, but I wonder how all those network-renderers would handle that? If I submit my scene to Muster (I'm most familiar with Muster), that would mean I have this single scene file so if I have to re-render some of the passes, how would that be?

this is probably an "easy" thing to do. output modules could be treated as separate entities. a slave renderer can be told to render out the "beauty" pass on Frame 10 by Muster ;). Muster, of course, is instructed, during its execution to render only specific passes, and tells the slaves to do so. it's similar in Maya. i dont think it's an issue.



I can live with 100 scenes IF a reference system would allow me to change things in one scene and all the others gets updated.

i'm trying out a new process / script in LW, using LScript. it involves making one scene file as the master. conceptually-speaking, a macro is run that defines what edits are made to the scene and outputs it automatically as a pass. in workflow terms, you only edit one scene file and run the script saying "i want to make a matte pass of this scene", and it outputs it. this matte pass, of course, must be user-defined beforehand. ideally, you should never have to edit that matte pass.

[jeremyhardin]

if LW's dev road does not integrate surfaces in scene files, the route that worley's G2 is probably the best way to go about it. i've seen users do on-the-fly surface modifications using G2's master (through pixel filter). if this is was enhanced and expanded to account for groupings of surfaces, etc etc, this could easily be, given the current LW architecture, one way to control a pass via surfaces.
indeed. though images are supported in both object and scene file format. and textures (such as displacement and animation textures) exist in both formats as well. it should be no great task to get object level surfaces and scene level surfaces, IMHO.
also, i think i should repeat this again from the newtek forums. i think a camera should be able to exclude objects from itself. if we imagine the camera as an output, a camera could treat one object as a matte object, while the other camera treats it as full-shaded. this is just thinking from the pov of the current LW system and the idea of how light excludes objects and viceversa. maybe a camera's interpetation of objects is easier / faster to implement right now, and is not necessarily a bad step. if it was implemented, then the "pass-cameras" can be compressed into one camera (having one unified settings), but its output and exclusion parameters broken down into user-definable ones. basically it's like what jeremy is saying, but in closer in current LW terms.
This certainly woudn't be my ideal, but as you said, it seems closer to LW's current system and may be the better route for now. Maya has independent camera output too if I'm not mistaken right? so I suppose it's not an unheard of idea.
i've successfully used Maya2LW2's reference system for cameras. it works pretty well and updates on the fly. of course, it's optimised for Maya to LW coordination. but LW to LW is still possible.I keep meaning to try it. :D How does it work with LW's non-motion camera parameters (and animation in those params)? And does it respect the new camera types in LW9?

however, without a doubt, LW really needs a SCENE reference system (we already have object referencing). not only does it double for render passes, but everything as well: particles, hypervoxels.... etc. there are too many examples why a reference system is needed.Agreed.

i'm trying out a new process / script in LW, using LScript. it involves making one scene file as the master. conceptually-speaking, a macro is run that defines what edits are made to the scene and outputs it automatically as a pass. in workflow terms, you only edit one scene file and run the script saying "i want to make a matte pass of this scene", and it outputs it. this matte pass, of course, must be user-defined beforehand. ideally, you should never have to edit that matte pass.That sounds like something I'd like to try. I spoke briefly with Dodgy about taking his LayersMC script further to have independent output, and he said he'd look into it. But if layers and independent layer parameters could be tied into the one scene concept (even if a behind-the-scenes multi-scene output is happening), then I think you'd be onto something quite useful. You've got my vote for this. Also, I've done a bit of text parsing in Lscript (as you know). If I can help, drop me a line and we'll see what the schedule looks like. :thumbsup:

[faulknermano]

i
I keep meaning to try it. :D How does it work with LW's non-motion camera parameters (and animation in those params)? And does it respect the new camera types in LW9?


i wouldnt know about lw9.. dont have it yet.

but it does support non-motion params. meaning the four animatable channels in LW, which is zoomfactor, blurlength (shutterangle), focaldistance, and fstop. if used with the scenecontroller that comes with Maya2LW2, aperture height is set too, but since it is not animatable, i couldnt externally hook it to a file. although, thinking about it now, if i could get the aperture height.

non-motion parms work by simply assigning a channel filter. but the code to retrieve the info is the same on all scripts (e.g. itemanimation, channelfilter). it's just interpretted differently for that architecture. all the info is stored in only one file (M2L). a camera would use IA and CF at the same time, and will reference the same M2L file.




That sounds like something I'd like to try. I spoke briefly with Dodgy about taking his LayersMC script further to have independent output, and he said he'd look into it.


ironically, Dodgy originally borrowed the LayersMC script from me (when it was DisplayLayersMC), but i think he totally changed it (just like i changed Maya2LW).

but i just never saw rendering as "layers". but i could always get the hang of it if the interface was right.

Also, I've done a bit of text parsing in Lscript (as you know). If I can help, drop me a line and we'll see what the schedule looks like. :thumbsup:

sent you an email. ;)

[Cageman]

WoW!!! This thread turned to be one of the best I've followed here at CGT. Both Jeremy and Lernie have experience outside of LW (XSI and Maya), so these two guys can make some great stuff together, given the time and passion.

I have no further ideas, I think you guys have summed it up pretty well regarding this topic. If I think about something, I'll sure post it here! :)

EDIT:
I'll stand for the passion and LOVE, and you guys, stand for the coding talent! ;) *LOL* :thumbsup:

[PetterSundnes]

If the whole structure of LightWave became object oriented, then we should be able to assign a pass to anything no matter how small or "insignificant" of an element it is. Even a selection of a few polygons could be set to have its own render pass, and within that again, only have the pass render out the diffuse of the shader applied to those polygons. And ofcourse, all of this accessible through a fully implemented JavaScript engine.

[druitre]

Fully agreed on the importance of this feature!

A suggestion/ thought: make it work like endomorphs already do for objects. So any change to the base scene carries over into all endoscenes, any change in any endoscene doesn't get reflected back into the base scene. The objectfileformat needs to be expanded for this with endo-surfaces, where creating a new endoscene automatically creates a new endosurface for each object.

That's all. Lots of detail to be filled in ofcourse, but the basics of this are not at all difficult to implement. Piece of cake. Only problem is I don't know anything about programming, so I could be dead wrong there...:)

[The-G-Man]

I still think that the PSD Export filter does an excellent job. However, I've yet to find anyone who knows the correct layer types / order to make it work as required.

[druitre]

@ G-Man,

I think you're confused. Rendering in passes has nothing to do with buffersaving, although it may overlap somewhat. Buffersaving doesn't allow you to have separate AO, shadow, key/fill, FG/BG, lead character/secondary characters, or whatever you can think of-passes, to be put together in comp.

Passrendering is a lot more powerful than saving out separate buffers of a render!

[The-G-Man]

@ G-Man,

I think you're confused. Rendering in passes has nothing to do with buffersaving, although it may overlap somewhat. Buffersaving doesn't allow you to have separate AO, shadow, key/fill, FG/BG, lead character/secondary characters, or whatever you can think of-passes, to be put together in comp.

Passrendering is a lot more powerful than saving out separate buffers of a render!

You are, of course, quite correct. Passrendering, although a lot more work, gives the artist ultimate control. However, utilising buffersaving can be useful, if only I could get the darn thing to work as I require. :eek:

[Brötje]

For those who use Ambient Occlusion with SG_AmbOcc.p...

It's really annoying to me that you can't render out an Occlusion-pass ( with Renderbuffer Export ) at the same time that you render an RGB.

There should be an option in the Renderpanel where you can set plugins that apply to the whole scene. And you should be able to save that pass at the same time all your other channels are saved.

That way, you won't have to render twice to get all the passes you need. For the Lightwave Team, I recommend that you take a look at SG_Ambocc.p. It's much more elaborate then Gmil.

CHEERS!

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.