PDA

View Full Version : Assorted wishes regarding the lighting department



deemon
02-16-2003, 05:21 AM
1. Intensity falloff for the Distant light type

Great for faking light bounces from flat surfaces like ground, floor, walls, etc

2. Radius option for the Distant light type so it could emit in a cylinder shape with adjustable soft edge.

3. Shadow map type and projection image options for the Point and Distant light types

4. "T" button instead of the Projection Image pull-down

5. "T" button for the Ambient Color

6. A plug-in class for implementing custom light type plug-ins

Elmar Moelzer
02-16-2003, 08:08 AM
Hello

I can second some of the wishes, but:
At1. With the current way Distance- Lights in LW work this would not be possible as LWs Distance Lights dont have a real position where should they start to falloff?
One would need a new Distance- light- Type for this, which is something I would love to see.

At2. See above

At3. Not sure Distant- Lights can work with Shadowmaps at all...

At4. Yeah I would love that too, even better: "lightshader" with a plugin- class for it.

At5. Hmm how would you imagine this to work, or what exactly is this supposed to do?

At6. Would be very cool! Though it might be more difficult to do, than what it looks like at first glance...

CU
Elmar

deemon
02-16-2003, 08:28 AM
>At1. With the current way Distance- Lights in LW work this would not be possible as LWs Distance Lights dont have a real position where should they start to falloff?
One would need a new Distance- light- Type for this, which is something I would love to see.

They would start falloff from their real position, obviously.

>At3. Not sure Distant- Lights can work with Shadowmaps at all...

If the Distants had the radius option I was talking about, shadow maps would not be impossible at all. Think spots that emit in a cylinder shape instead of a cone.

>At5. Hmm how would you imagine this to work, or what exactly is this supposed to do?

A simplified example: imagine a spherical environment map with a Sky/Ground gradient that controls ambient color -- this way you could have blue ambient color from the top and brown from the bottom. Or have it from the top only. Or add an animatied texture simulaling cloud shadows on every object in the scene. Lots of uses, just think about it.

Lightwolf
02-17-2003, 08:57 AM
Originally posted by Elmar Moelzer
Hello

I can second some of the wishes, but:
At1. With the current way Distance- Lights in LW work this would not be possible as LWs Distance Lights dont have a real position where should they start to falloff?
One would need a new Distance- light- Type for this, which is something I would love to see.


We meet again :-)

1) would work taking the XY plane of the distant light into account.

But, for 1-3, I would suggest a cylindrical spot light (Actually, I already did some time ago).

A Light Plugin class would be really cool, one could finally write lights that support deep shadow maps, as well a spot lights with shadow maps...

I wish...
Cheers,

Mike

Elmar Moelzer
02-17-2003, 10:22 AM
Hello
Hmm if one had spotlights with adjustable base one would not need distant- lights with falloff right?
One could use that spotlight, same for shadowmaps on Distant- lights (unlimited Distantlights cant have shadowmaps as a shadowmap needs to have an extend).
I would rather suggest adding a base Radius to the spotlights, would be easier to do and would have it all, right?
The problem with the texturemaped Ambient-light is that the Ambient- light as it is now has no direction. It is simply more like a luminosity added to all surfaces. Something like you suggested would be more like what lightgen does. This certainly does not render fast and it would rather require another type of light, like a Spherelight or something, rendertimes would be like an Arealight or more likely much higher.
CU
Elmar

deemon
02-17-2003, 10:42 AM
>Hmm if one had spotlights with adjustable base one would not need distant- lights with falloff right?
One could use that spotlight, same for shadowmaps on Distant- lights (unlimited Distantlights cant have shadowmaps as a shadowmap needs to have an extend).
I would rather suggest adding a base Radius to the spotlights, would be easier to do and would have it all, right?

The point is to have a light with _parallel_ rays, with falloff and shadow maps options. Whether will it be a spot with its base being equal to its other end, or a distant with the radius option, personaly I don't care as long as its there.


>The problem with the texturemaped Ambient-light is that the Ambient- light as it is now has no direction. It is simply more like a luminosity added to all surfaces. Something like you suggested would be more like what lightgen does. This certainly does not render fast and it would rather require another type of light, like a Spherelight or something, rendertimes would be like an Arealight or more likely much higher.

I don't think you got it right there. Probably my explanations weren't clear enough. It's nothing to do with LightGen and it would certainly render fast. I do know what I'm talking about since I've already used this technique, just with 3rd party plug-ins.

Lightwolf
02-17-2003, 10:56 AM
Hi Elmar and deemon,

I think what deemon means with the ambient light, is basically a "reflection" map, but one that only influences the ambient term in the shading process.

And yes, that would make sense.

On the other hand, I'd like lights to be much more procedural anyhow, that way we could even add light colour gradients to lights, based on the incidence angle on an object for example :)

Cheers,

Mike

deemon
02-17-2003, 11:08 AM
Lightwolf, that's correct re ambient stuff -- it's merely a scene-wise environment map on luminosity that can have color, textures, and stuff.

Lightwolf
02-17-2003, 11:33 AM
Hi deemon,

yeah, I thought about soemthing like that too, would be really cool.

I just hope that LW gets more and more flexible, because I'd then see lights like that popping up as plugins.

Matt
02-17-2003, 11:43 AM
Can we also have a HUGE speed boost for any lights that produce soft shadows (area, linear)

Better on screen representation for linear lights, a single line IS NOT enough, difficult to see in a complex scenes!

Custom sampling threshold for area / linear lights (or any future soft shadow lights)

Or when area/linear lights are scaled up they DON'T become grainy!

:D

Halsu
02-17-2003, 01:33 PM
I thought i'd do shameless self promotion here ;-)

My Overcaster Ambimage lighting rig (part of my plugpak) more or less takes care of wish n/o 5: it sets up ambient lighting with 24 distant lights, getting the settings either from an image, BG, BG gradient or a manual gradient.

If the user leaves shadows off, it gives very quick adjustable ambient solution. If the shadows are on, the result is rather close to BG radiosity, but there's a render time hit...

There's also multiple spinning light rigs in the PlugPak for quicker rendering soft shadows.

http://www.kolumbus.fi/erkki.halkka/plugpak

deemon
02-17-2003, 01:50 PM
Eki,

Your Overcaster is nice but is no replacement for #5. Even with shadows off a simple textured ambient would render much quicker than 24 lights, not to mention you still cannot have this ambient textured in a simple way.

It's not that "T" button for the ambient would give something you cannot do right now, it's just it is an obvious (well, to me anyway) way to improve the tool, which in its turn can save some time for an artist.

deemon
02-17-2003, 04:28 PM
A quick example of ambient (IFW2 shader), which color is controlled by another IFW2 shader (gradient). Not the best example but you can get the idea.


http://www.savinoff.com/stuff/ambient.jpg

Hope the image shows up correctly

Halsu
02-18-2003, 11:48 PM
Hi Deemon!

I attached another comparision image... cool color, huh?

;-)

As you can see, you can do pretty much the same thing with OC ambimage, as i said (not exactly though).

And it really doesn't take a long time to render.

You can automaticly texture the OC ambimage ambient by getting the coloring from the background or from an image. Or, you can set it up (or modify the automatic result) manually.

Textured ambient WOULD be very cool, but untill we get it... If you wish me to try to reproduce your example, you can send me the scene/objects and i'll have a try...

deemon
02-19-2003, 03:53 AM
Hi Eki,

I'm sure you can replicate that Venus ambient, one doesn't even need plug-ins for that; just 8 lights if you're planning to fly around the statue and just a couple if it's for a still. What I was trying to say is that it would be nice feature to have, I know where it would save my time and what cool effects I could achieve with it. Wouldn't take a great deal of programming efforts too. I don't expect this feature to be useful for every LightWave user out there, just like I hardly find useful for me personaly a lot of the feature requests being posted here. To each his own.

Oh, you did warn it's going to be a shameless self promotion :)

McLeft
02-19-2003, 01:10 PM
What can be easier that "T" button on Ambient that is part of software.... pair of clicks...
I think it's better than fiddle with with set of scripts...
And i think it's a time to move to node based Shading tree....
where you wont need to think where to add "T" button :)

Halsu
02-19-2003, 02:37 PM
Yep, it would be a cool addition... i was just shamelessly promoting an alternative that's available NOW ;-)

As far as node based surfacing goes... yep, i guess it does have it's points, but in most situations the current quick and dirty way is really efficient.

McLeft
02-19-2003, 05:46 PM
well, you end up with same procedural texture applied on multiple channels quite often.... and tweaking such surface turns into hell...

deemon
02-19-2003, 05:57 PM
... not to mention this whole blending mess -- constructing something with multiple alphas and other blending modes quickly becomes a nightmare once you have many layers. Probably it would make sence to have both schematic and the present surfacing modes; I agree that unlike the node-based stuff the current way is very efficient for simple surfaces.

Lightwolf
02-20-2003, 02:20 AM
... plus, if they do it properly, you could share texturing nodes between different kind of textures, like shading displacement, clipmaps and texture motion.

Eki... Like, automatically bob an object on a displaced ocean surface... And you'd only need to tweak one texture node to change the displacement and the bobbing movement...

Hm, I need to have a look at that Houdini thang again :-)

Halsu
02-20-2003, 03:50 AM
Yep, that would be cool - but it doesn't necessarily have to mean node based surfacing. First thing that comes to mind would be one more option to current layer types: you could have

Image map
Procedural
Gradient

and the new one

Other channel


Selecting the "other channel" option would have a popup with "Surface","Displacement", "textured Environment" etc. - whatever texture types there are in LW.

Okay, let's assume the user selected "Surface", and activated one of the surfaces in the current scene.

There would be one more popup: "Color", "Luminosity", "Diffuse", etc. surface channels.

Futher, there could be an option to select a single layer, or all layers.

Selecting all layers would make the "other channel" layer use i.e. diffuse channel's all texture layers combined, as texture as the current layer.

This way you would only have to modify one surface to affect zillion others...

It could probably be simplified more, i'm making this up as i type ;-)


Originally posted by Lightwolf

Eki... Like, automatically bob an object on a displaced ocean surface... And you'd only need to tweak one texture node to change the displacement and the bobbing movement...

Yep... In my SeaGen, the bobbing is automated like this, and modifying the displacement works perfectly as long as it's only done with the sliders that control SeaGen. If the user modifies the displacement textures manually, the "sync" is lost...

Halsu
02-20-2003, 05:01 AM
Here's an interface mockup i made - actually, it doesn't look too confusing even like this -

deemon
02-20-2003, 05:20 AM
Hmmm.... a ton of clicks just to make the surface use some other surface texture... :) What can be more intuitive here than just visually linking respective nodes?

Chris S. (Fez)
02-20-2003, 05:50 AM
Ever used Shake? The workflow with nodes is so sweet. Having an interactive render that updates as you make and break connections would be welcome...

Lightwolf
02-20-2003, 05:56 AM
Originally posted by Halsu
Yep... In my SeaGen, the bobbing is automated like this, and modifying the displacement works perfectly as long as it's only done with the sliders that control SeaGen. If the user modifies the displacement textures manually, the "sync" is lost...

Well, for a similar problem to that, I wrote a motion plugin that reads out the displacement map of an object and applies it as a motion, so there is only one texture to edit as well.

Still a bit kludgy. And I agree, it wouldn't have to be node based, but it would be more intuitive with more complex setups...

Halsu
02-20-2003, 06:11 AM
Originally posted by deemon
Hmmm.... a ton of clicks just to make the surface use some other surface texture... :) What can be more intuitive here than just visually linking respective nodes?

That would be exactly 5 clicks in my example.

I don't really think that's much, as one would have to find a way to locate the correct channel anyway... as there can easily be thousands of them in a scene, there's no way they all could be shown at once.

What would you suggest as an easier way to select the channel to be followed?

And, if this was done as a texture layer as in my example, doing the same thing to the rest of the cannels would be a single copy/paste.

How many clicks the same thing would require if node based? What would be the workflow?

Lightwolf
02-20-2003, 06:24 AM
Well, I wouldn't count mouse clicks :)

But, a node based system makes it easier for you to see what is actually going on.
With your (I have to admit, workable and with the sdk even possible solution) you have no idea at one glance of what is going on.
On a node based system, with one glance you see for example which textures actually reference your master texture.
So, if you're object doesn't bob properly, because its not connected to the master texture, you'd see it in a jiffy on a node based view, whereas currently you'd have to click your way through a whole bunch of windows...

deemon
02-20-2003, 06:31 AM
5 clicks is a lot for such simple operation. Currently it takes 6 clicks to copy a texture from somewhere into the needed channel. Not a heck of an improvement, IMO. But it's not just about an amount of clicks, actually. It's about a convenient and flexible way to quickly edit and reaarrange your complex surface.

And by the way, depending on how exactly the nodes implemented and look, it may take just as little as one click to connect any channel to any other channel -- click and hold -> drag -> drop.

Halsu
02-20-2003, 07:13 AM
Well, maybe both would be good... like the parenting stuff currently - you can do it in mutiple ways, including nodes in the schematic view.

Lightwolf
02-20-2003, 07:22 AM
I agree with you there.

If in doubt, agree on both options :D

deemon
02-20-2003, 07:35 AM
I too agree that the more options the better. My ultimate wish is to see the next LightWave version as open as it can be, with a possibility to replace every its part by 3rd party solutions should there be a need.

Lightwolf
02-20-2003, 07:45 AM
Well, I couldn't agree more with you.

It will make it a hot harder for newtek though:
* The UI would need to be revamped a bit more, and streamlined to be more flexible. (Without it starting to look like Max, Maya or XSI).
* We will run into compatibility problems (but those we have already anyhow-> BRDF and Radiosity, HV and reflections, dependancy problems with expressions etc...)

On the other hand, if they have somebody who's dedicated job it is to watch over the SDK and help developers, you'd see third party stuff pop up in no time (look at what happened when the LScript Docs got released).

adboy
02-20-2003, 08:30 AM
and an on/off switch please

thats gotta be an easy one