Surface (material) that doesn't cast shadow, but receives shadows?

Started by motorsep, July 28, 2015, 02:53:23 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

motorsep

Is it possible to have a surface (material) that doesn't cast shadow, but receives shadows from other objects?

For example, if you have a cube that casts no shadows itself, but if a monster stands next to it, monster's shadow would be on the cube.

It might be working by default, but I never actually tested such setup and wondering if it's already supported.

aphexjh

"noShadows   Don't cast shadows"

is this not what you mean? I know it's super obvious, but this seems to be what you are asking about.

nbohr1more

"noselfshadows" is sorta what you are looking for but keep in mind that it this will cause the following behavior:

Receiving surfaces that are also "noselfshadows" will not show shadows that are cast by "noselfshadows" objects.

So as long as the monster was not set to noselfshadows, the cube would receive the shadow from it while also casting
shadows onto the monster.

http://wiki.thedarkmod.com/index.php?title=Noselfshadows

motorsep

I think I didn't make a clear description.

Cube has material A, which has "noShadows" and "noSlefShadow" keys, so it doesn't cast shadows neither on the world nor on itself. Monster has material B, which is a standard material that casts shadows on the world and on itself.

Will the cube receive monster's shadow ?

aphexjh

Is this a logic riddle? Motorstep, I feel like you could easily test this.

motorsep

I am at work - can't test it :D I will when I come back home, but I was just wondering if anyone tried it / knows about it.

aphexjh

Yea, well I am pretty sure noShadows is what you want. Doesn't cast shadows on other objects, but still receives shadows from other objects.


motorsep

Now the issue is with shadows. If I have material fullbright (any material), the shadow that is cast on it will be so faint, that it would appear as if there is no shadow. Apparently can be fixed in the interaction shader, but it's over my head :/

I've been brainstorming lightmapping technique for id Tech 4 and it seems like it would work, if shadow over fullbright material is fixed. It would work fine as is, but dynamic objects will have faint shadows.

Another step would be adding support (unless already supported) for 2-nd UV map in ASE/LWO and access to that in the material system. Then lightmaps can be baked to second UV map.

oneofthe8devilz

I got six little friends and they all run faster than you ;)


Check out our mods at
moddb or the SPS Homepage

motorsep

Quote from: oneofthe8devilz on July 29, 2015, 10:31:50 AM
Lightmaps are so 1996 :o (Quake)

yeah, that's why UE4 / Unity 5 / Source 2 / id tech 5 / etc. still use lightmaps in 2015 and will be using them for years to come.

oneofthe8devilz

#11
Quote from: motorsep on July 29, 2015, 10:44:43 AM
yeah, that's why UE4 / Unity 5 / Source 2 / id tech 5 / etc. still use lightmaps in 2015 and will be using them for years to come.

And I guess that's why Cryengine, Frostbite 3 and id tech 6 are NOT using lightmaps...

It's a static form of lighting that should be buried with the past generation of games.

One of the reasons why idtech5 was abandoned (aside from static megatextures and their enormous build time and renderfarm requirement) is the amount of static light calculation time required to bake in the static lightmaps...

Aside from looking like crap it simply is quite an ineffective way of map creation.

Especially for small indie teams like us, lightmapping can be a very tedious time and resource consuming process...

In real-time generated lighting is just so much faster to work with during the development process and it just looks so much better being dynamic, so you end up with 2 distinct advantages (fast development iteration and dynamic scenes) over one smaller disadvantage (more hardware demanding) which loses significance over time as hardware advances and gets faster...
I got six little friends and they all run faster than you ;)


Check out our mods at
moddb or the SPS Homepage

motorsep

I'd like to see id Tech 4 / BFG getting any reasonable real-time GI solution any time soon, optimized to run well on average PC. It ain't gonna happen. Even shadow mapping in BFG has quite a few issues tr3b hasn't been able to solve. There is a good chance that engine has to be rewritten in parts to accommodate, properly, modern real-time GI.

Note that neither Frostbite nor id tech 6 are available to the public and most likely will never be.

Lightmaps baking is not that slow as you think it might be, in Blender, since it uses CUDA.  Lightmaps are still quite relevant and you don't need 100% real-time solution if you don't have dynamic day/night cycle in the game.

And if someone would choose engine for arch viz, lightmaps is the way to go (and if arch viz is done without any dynamic models moving around, there is no need in any modification - engine can do it already with some hacks)

Don't get me wrong, real-time lighting is the future, but that future isn't quite here yet. Unity 5 is the only engine that uses Enlighten and anything UE4 is still in alpha stage. CE EaaS has light propagation volumes, but CE EaaS is the worst engine out there when it comes to usability/support.

I am mostly experimenting with lightmaps for arch viz / VR (if we ever get VR support in our engine).

oneofthe8devilz

Yeah, VR is in some kind of a catch-22 situation here...

On the one side it has those insane hardware requirements 2k/4k/8k/16k Displays + StereoScopic (per eye) @ 60/120/144 Hz which will keep growing the more highres the displays for the headsets get and on the other side because of the "immersive" factor, static technologies like lightmapping become even more apparent to the consumer in such a VR environment...

A "perfect" VR experience with a dynamic game-engine would probably require a 16K Display (to completely eliminate any screendoor artifacts) @ 120 Hz in Stereo 3D (per eye) which equals about 256 times the performance that a current PC needs to run a game at 1080p @ 60 FPS in MonoScopic.

I got six little friends and they all run faster than you ;)


Check out our mods at
moddb or the SPS Homepage

aphexjh

I would like to see light-maps in tech 4.  I agree with Devilz that it will slow down production, but lighting a scene would be easier, more realistic and could save on performance, especially since many static lights don't really need to be added to the dynamic light calculation. I know you guys know how painful it can be to optimize a map so that the light volumes aren't overlapping everywhere, and how much of a pain it is. On the other hand, working with static and dynamic lights and shadow casting objects can be its own kind of headache.

[insert picture of dynamic shadows casting through floors] 

But back to the whole "sooo 1996" thing, yes light-maps are sort of archaic and unrealistic, but they can also make spaces look really nice. The whole issue is not unlike production for a 3d film. It's really a question of time and money. How much time can you afford to take to render each frame? And, what do you want to spend that time on? If you have the time, and the aesthetic fits, a good light-map solution can make the scene look amazing.