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.
"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.
"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
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 ?
Is this a logic riddle? Motorstep, I feel like you could easily test this.
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.
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.
Aye, it works.
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.
Lightmaps are so 1996 :o (Quake)
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.
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'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).
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 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.
"1996" Lightmaps in 2015:
https://forums.unrealengine.com/showthread.php?77135-Unreal-Bathroom-with-Shield-port
https://forums.unrealengine.com/showthread.php?72638-Loft-in-London
https://www.youtube.com/watch?v=eTt7AGIpV2I
I don't optimize lighting in id Tech 4 (or rather BFG engine). Dmap clips overlapping light volumes anyway. Modern hardware runs unoptimized maps just fine (unless lighting is _really_ crazy).
Lightmapped games look really much better than any of id tech 4 games. It's just a fact, even if you go stylized with art style.
Quote from: motorsep on July 29, 2015, 11:12:42 AM
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.
Guys, buy me time or use Unreal 4 :)
https://www.patreon.com/RobertBeckebans
Concerning lightmaps ... this is Q3A/XreaL style vertex lighting that I added for the mobile path
http://imgur.com/a/wPFV5
Quote from: trebor on July 29, 2015, 02:06:33 PM
Quote from: motorsep on July 29, 2015, 11:12:42 AM
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.
Guys, buy me time or use Unreal 4 :)
https://www.patreon.com/RobertBeckebans
Ouch, graphics development ain't cheap :(
Not D3/UE4/etc. tech, but Berserker Q2 combines Lightmaps + real time. Any RT lights override what the lightmaps rendered out, so that shadow caused by a wall can be lit up & light areas can be made darker. Entities have real time shadows and there's the option for the world or entities only displaying them.
The advantage (when I was playing with it) was I could render my static sun for outdoor scenes & my entities (projectiles & the like) would display like I expected them too.
I find setting up a map for a decent render time with lightmaps just as cumbersome as setting up for efficient real time lighting and I still prefer the D3 look over the static lightmap look of modern games. I'd say it comes down to personal taste & the atmosphere you want to convey.
I think this realtime GI technique is very cool and it is way faster than voxel cone tracing
https://www.youtube.com/watch?v=SXEDMv6VaSc
Quote from: trebor on July 29, 2015, 03:55:05 PM
I think this realtime GI technique is very cool and it is way faster than voxel cone tracing
https://www.youtube.com/watch?t=45&v=SXEDMv6VaSc
Not showing :/
Quote from: The Happy Friar on July 29, 2015, 03:50:00 PM
Not D3/UE4/etc. tech, but Berserker Q2 combines Lightmaps + real time. Any RT lights override what the lightmaps rendered out, so that shadow caused by a wall can be lit up & light areas can be made darker. Entities have real time shadows and there's the option for the world or entities only displaying them.
The advantage (when I was playing with it) was I could render my static sun for outdoor scenes & my entities (projectiles & the like) would display like I expected them too.
I find setting up a map for a decent render time with lightmaps just as cumbersome as setting up for efficient real time lighting and I still prefer the D3 look over the static lightmap look of modern games. I'd say it comes down to personal taste & the atmosphere you want to convey.
The problem with Q2/Q3 based engines is that there are no good tools to bake lightmaps. For D3 any 3D app will do. Better, faster, more efficient.
Nothing cumbersome about light maps, especially when working in Blender. Turn on real-time preview and tweak lighting until satisfied. Set to bake and go get some tea/coffee/dinner/etc. Save texture and all done.
Again, since currently it's more theory than practice at this time (and there is no good way to incorporate dynamic shadows into the thought out setup), there might be some gotchas that aren't obvious to me currently :)
Don't get me wrong, having IBL probes and SSAO would be cool. Having real-time GI would be even better. It's just have to be well integrated into the engine, and optimized. No one out there will do that. So realistically, it's easier / less expensive to come up with lightmapping solution for certain projects.
I updated the link. The full presentation is at http://graphics.cs.williams.edu/papers/DeepGBuffer14/
Quote from: trebor on July 29, 2015, 06:24:47 PM
I updated the link. The full presentation is at http://graphics.cs.williams.edu/papers/DeepGBuffer14/
Quite interesting. Does implementing G-Buffer automatically mean that deferred rendering pipeline has to be implemented ?
No I think the G-Buffer is only used for the indirect lighting term. It is the first technique that runs within 3 milliseconds here. All other realtime GI demos ran like shit on my system.
Cool :)
Strangely, it crashes here: http://www.pasteall.org/59975
Nice, it runs quite fast on my machine...
Though I still have trouble to get used to all the latest "screenspace gfx hackery"... where the action has to happen on screen in order to be able to be processed...
Quote from: motorsep on July 29, 2015, 07:26:29 PM
Cool :)
Strangely, it crashes here: http://www.pasteall.org/59975
Replace the file with this one https://dl.dropboxusercontent.com/u/22890478/g3dmath.glsl
Quote from: motorsep on July 29, 2015, 04:30:23 PM
The problem with Q2/Q3 based engines is that there are no good tools to bake lightmaps. For D3 any 3D app will do. Better, faster, more efficient.
Nothing cumbersome about light maps, especially when working in Blender. Turn on real-time preview and tweak lighting until satisfied. Set to bake and go get some tea/coffee/dinner/etc. Save texture and all done.
I've done it with importing to to Berserker as an entity model & then the RT lights work but the current .map exporters for Blender do it pretty hacky (IE make brush soup) & then there's no way to get the baked texture on to the brush. :( Because of this (and Berserker always liked to crash for me) I decided any Q2 work I do should be stylized to not look anyway realistic in lighting.
Quote from: trebor on July 29, 2015, 07:48:45 PM
Replace the file with this one https://dl.dropboxusercontent.com/u/22890478/g3dmath.glsl
That worked, thanks.
I don't know if it's because it's hot in my house or something else, but shortly after I loaded Sponza, my GPU fan went berserk and PC shut down :/ Odd.
I noticed that AO is super grainy. Nothing what they show on video / screenshots unfortunately.
@trebor: What do you think of this http://wili.cc/research/ffao/ ?
That can happen quite often with research demos that don't enable vsync :D
You need a better power supply and it will be fixed.
Dunno ffao does not look really special but the implementation seems to be complicated and requires cuda.
Quote from: trebor on July 30, 2015, 07:11:33 AM
That can happen quite often with research demos that don't enable vsync :D You need a better power supply and it will be fixed.
Aye, I thought my GPU overheated :)
Quote from: trebor on July 30, 2015, 07:11:33 AM
Dunno ffao does not look really special but the implementation seems to be complicated and requires cuda.
It looks quite good and it performs well (judging by the video and description), so I figured it's the best solution there is (as far as performance/quality ratio). I wonder if cutting CUDA dependency out would impact performance.