PDA

View Full Version : Add support for Alembic, OpenColorIO and Open Shading Language



lordtangent
08-24-2010, 01:49 PM
Now that Sony has open sourced Alembic, OpenColorIO, Open Shading Language http://opensource.imageworks.com Newtek should support them. Alembic in particular would add a lot of utility to LW10 in th sort term, by allowing for what would essentially amount to an off-the-shelf hybrid pipe-line with Maya and other tools. OpenColorIO would be a great way to expand the new linear color work flow to work seamlessly with other color spaces.

Open Shading Language support would be a nice feature, but maybe over-kill? I guess it depends on who you ask. Once Alembic support was working rock solid, you might find a lot of high-end users with very specific expectations using LW as a back-end for rendering.

Lightwolf
08-24-2010, 02:00 PM
OSL is certainly overkill by the looks of it. It seems to be a good way to integrate shading into a system that doesn't have it - but that's as far as it goes.

Cheers,
Mike

Tobian
08-24-2010, 04:10 PM
Hmm fascinating. the OSL shaders sound nice, though they may not be very efficient or optimised, they support light emitting surfaces, which LW sorely needs! :)

Lightwolf
08-24-2010, 04:39 PM
Hmm fascinating. the OSL shaders sound nice, though they may not be very efficient or optimised, they support light emitting surfaces, which LW sorely needs! :)
Actually, it's quite clever. The run the shaders through a compiler to create native code (but that part isn't quite done yet).

Mind you, neither of these projects are at a V1.0 stage yet.

Cheers,
Mike

Tobian
08-24-2010, 05:02 PM
Well that's not always the point. Sometimes building something on clever ground means you get something good out of it. I am tired of seeing stupid and bodged ways of making things work (which sadly is about 80% of computing, or more haha). Open standards however are also notoriously glacially slow to appear! :D

Sensei
08-25-2010, 11:25 AM
Hmm fascinating. the OSL shaders sound nice, though they may not be very efficient or optimised,

I don't quite see sense. After all, all shaders would be written by programmers, not 3d graphics artist, so it's better to have them compiled immediately to C/C++ optimized code, utilizing KD-Trees, multi-threading, multi-core etc etc
MS Visual C/C++ compiler is free, X-Code for Mac is free. Any 3d artist can try writing nodes or shaders. But you don't do that, because of lack of knowledge. Shaders in text files won't give you knowledge. They will just work slower, than C/C++ native code.


they support light emitting surfaces, which LW sorely needs! :)

In LightWave any surface is emitting or eating light.. Instead of plugging 2d texture directly to Color input, plug it to Math > Vector > Scale and then to Color. In Scale node use 500%..1000% (or -500%.. -1000% if you want to eat light), enable GI (default settings), and you will see how your 2d texture is emitting/eating light to/in scene.

Default range of RGB color in 0.0... 1.0 is quite neutral, but if it's exceeded, then it's starting to be visible as emitter.

Tobian
08-25-2010, 11:41 AM
Erm Sensei... GI and light emitting polygons are NOT the same thing.. Light emitting polygons send out rays... and therefore work without needing GI enabled...

Luminous surfaces in a GI solution do not...

The lack of proper light emission from surfaces in LW is a problem because it means you cannot do properly realistic small area super-luminous emitters without extreme blotching issues...

Take a small ball light, the size of a light bulb, and put it in a scene, and set it to have realistic inverse square falloff. You will get pleasant lighting, crisp but soft shadows, and with some Gi bounces, and Linear colour, a pleasant blotch free render without insane radiosity samples

Now take a ball shaped object, set it's luminosity to be 10k or so.. and what will you get.. Something quite horrendous even with several thousand RPE's Blotchy shadows, no crisp shadows, major blotching issues.

In some of the more modern bi-directional MTL radiosity engines, which can send out photons from luminous surfaces, or make them behave like lights, then this kind of scene will be fine, because there is no real difference between a small luminous object which is very bright, and an area light. LW has no current way of doing this except for DP's light plugin which can read polygon data, but it's horribly slow to use except for a few polygons.

Lightwolf
08-25-2010, 11:49 AM
I don't quite see sense. After all, all shaders would be written by programmers, not 3d graphics artist, so it's better to have them compiled immediately to C/C++ optimized code, utilizing KD-Trees, multi-threading, multi-core etc etc.
Not quite, OSL can compile complete shading trees into one shader, prior to rendering.
None of the other issues come into it anyhow (KD-Trees, multi-threading, multi-core) - unless the shaders themselves aren't safe.

Cheers,
Mike

lordtangent
08-25-2010, 11:35 PM
I'm amused to see I stirred up such a ruckus with my LOWEST priority feature request.

Anyway, programmable shaders would be nice a nice option, if only to attract high-end users who think they need them. Of course, there is already renderman SL, but OSL is more "ray-trace savvy" by design. It seems to make more sense to me than throwing back to RSL. But everyone please keep the request in context. I'm not even sure it's worth it. I guess it would really depend on how hard it would be to implement.

I doubt I personally would ever use them, since LW nodes are so flexible a full on shading language probably isn't required.

What I would REALLY like to see is Alembic, which would probably be an improvement over trying to use MDDs for that sort of stuff.

Lightwolf
08-26-2010, 01:35 AM
Anyway, programmable shaders would be nice a nice option, if only to attract high-end users who think they need them.
Well, if programmability is the only reason for the request then there is no point, you get that with a copy of the SDK.

Cheers,
Mike

Tobian
08-26-2010, 06:19 AM
Yes Renderman shaders aren't necessarily designed with all the high-end raytracing functions like BSDF or MLT etc. As for programmable, I prefer nodal shaders, especially if they are cleverly and efficiently designed, so they don't cause as much slow down.

It's a bit too early to see if Alembic will live up to it's promises yet, but it could be a very cool file format indeed!