PDA

View Full Version : Why is ObjectID in Lightwave?



studlybw
09-02-2011, 02:41 PM
Admittedly I'm no professional when it comes to LW, but I can fake my way around to get things done. Having said that, in all of my research of ObjectID buffers all I find is people saying that they don't actually work. That's my experience when outputting them in RLA and RPF formats and importing into AE.

Why does Newtek continue to package ObjectID buffers in LW when they obviously don't work. It seems like the ability to matte and work with individual objects is a pretty useful feature of a 3D program but, even in LW10, you still can't do it. :question:

Red_Oddity
09-02-2011, 03:01 PM
It's not LW, ObjectIDs work perfectly fine in Fusion, leave it to Adobe to frack simple implementations of standards up.

Lightwolf
09-02-2011, 04:44 PM
Well, for one they do starting with 10.1 - the last remaining problems creating them have been fixed (along the surface IDs).
However... the general concept of both ID buffers is flawed (and that's true for any implementation of the concept - be it 3D renderers or compositing applications).
It breaks down once a pixel contains colour information due to more than one surface or item (as is the case in border situations when rendering with AA).
Effectively they have no AA (and can't due to their nature).

Other than that though... they work just fine now.

Cheers,
Mike

Sensei
09-02-2011, 05:06 PM
It breaks down once a pixel contains colour information due to more than one surface or item (as is the case in border situations when rendering with AA).
Effectively they have no AA (and can't due to their nature).


That's why I am fan of rendering without AA and double/triple resolution, then rescaling to final resolution at the end.. ;)

Lightwolf
09-02-2011, 05:22 PM
That's why I am fan of rendering without AA and double/triple resolution, then rescaling to final resolution at the end.. ;)
Which is fine if you don't need more AA. But it can always be a mixed approach as well.

Cheers,
Mike

nickdigital
09-03-2011, 12:26 AM
That's why I am fan of rendering without AA and double/triple resolution, then rescaling to final resolution at the end.. ;)

OLM Smoother might be useful on top of this too.
http://newtek.com/forums/showthread.php?t=121402&highlight=olm

Greenlaw
09-03-2011, 11:31 PM
Yes, OLM Smoother was just brought to my attention by another user (thanks wellsichris!) and it seems to work fairly well, if not perfectly. The plug-in is for AE but it works in 32-bit Fusion too.

For that matter, we can probably do something like this using SmoothKit (http://www.revisionfx.com/products/smoothkit/features/) from ReVision FX. SmoothKit is a commercial plug-in (OLM Smoother is free,) but it has a lot of other features and it should be a bit more tweakable. I'll try to give it a shot for this purpose this weekend.

What we really need is access to Z Coverage. We get this out from our Vue renders when rendering RPF, and when used in Fusion it automatically applies AA to the Object ID, Material ID, and Z Depth selections. This means we almost never need to render special mask passes for Vue renders for Fusion.

Curiously, Lightwave's Extended RPF Saver has the option to save Z Coverage but it doesn't actually save this data...what gets saved is just the alpha channel. I really hope Newtek can provide us real Z Coverage data in the next Lightwave build as this is an incredibly useful feature.

BTW, here's a useful tip: our Vue RPF files are insanely huge and will bog down our Fusion comps, so what we do is save an EXR for the floating point 'beauty' pass at the same time as the RPF (Vue lets you do this,) and then in Fusion we merge the Object ID, Material ID, and Z Coverage data from the RPF with the highly compact EXR file. The smaller file size speeds up our comps tremendously while giving us a lot of flexibility.

Naturally, if Z Coverage is ever enabled for Lightwave, I would like to bypass the RPF format and just have it embedded directly to EXR, either natively or through exrTrader.

G.

jeric_synergy
09-06-2011, 11:09 AM
??? Why would they include that buffer if it's not actually functional? Why not just leave it out?

Greenlaw
09-06-2011, 11:52 AM
But it is functional...sort of...it's currently just not as useful as it could and should be. Leaving it out entirely would be, uh, less useful. :)

G.

Greenlaw
09-06-2011, 11:56 AM
Oh, wait...I just realized that you're talking about the Z Coverage button in the Extended RPF saver. Yeah, that is weird that it's in there at all. I guess it was put in for 'future use'.

I wish the future was now. :)

G.

jeric_synergy
09-06-2011, 02:00 PM
Yeah, Z-coverage.

Seems that instead including it just muddies the water. <|^\