Thanks man. I am not as experienced as you but let me put a "my feelings exactly" here.
Thanks for sparing time to write all this.
Inpw
Yeah lookin col mmate. Do you guys have any problems in performance when nay units go at each other in the ame screen ?
marks
Yeah, I remeber it is not "baking" exactly but it is something like a "precomputing" thing.
All I know is I played a game made with Enlighten and it nearly killed my machine (PC). But then again maybe it was havingperformance issues that are soled today ?
Yeah lookin col mmate. Do you guys have any problems in performance when nay units go at each other in the ame screen ?
Nope, we do not have such problems. Actually there are not too many units in the same time even in mass scenes. Terrain on the other hand a very resource-intensive. So small advice for those who interested: it's better to use custom external terrain.
Back to the topic. Why would you want dynamic GI in RTS game ? I mean really..
I can understrand need for dynamic GI in something like sandbox RPG, for that matter any sandbox game, as they tend to pretty open ended and dynamic in their own way, where nothing is set in stone.
Plus, players are usually quite close the the environment (FPP or TPP).
But RTS ? Camera is on top, and most players would be more than happy to put in even higher and replace all units with moving icons. Just sayin. That's how I'm playing Planetary Annihilation ;p.
Even fairly unit centric games like Dawn Of War 1/2 won't benefit much from advanced lighting.
Icons or iconic art is a good point with RTS, while integrating assets is a nice thing for anything static, too well integrated units might destroy readability at a distance.
Besides that simple bouncelight fakes can be integrated via ambient cubemaps, which are a a lot lighter than realtime GI.
claydough: nobody says that realtime GI is a bad thing, and it will come, no question about it. And it will be used where it makes sense, and possibly everywhere at a time where the computation costs can be ignored. But we are far from that point.
I was thinking about writing this last paragraph with a heavy german accent in it, to illustrate how hard it is to follow you thanks to your written dialect, would be really cool if you could drop it, just for the sake of readability.
I think Claydough missed the part where we all realized that Tan seemed to be mixing up realtime lighting with realtime GI. It seems like what Tan's actual goals --no baking lightmaps/shadowmaps in an RTS-- are are totally feasible.
Also, you can tell who in this thread has actually used Enlighten based off of how jaded their replies are. :-(
I think Claydough missed the part where we all realized that Tan seemed to be mixing up realtime lighting with realtime GI. It seems like what Tan's actual goals --no baking lightmaps/shadowmaps in an RTS-- are are totally feasible.
Also, you can tell who in this thread has actually used Enlighten based off of how jaded their replies are. :-(
i dont think he was talking about realtime lighting, because frankly every 3D engine has that.
as to enlighten; its a pretty complex technology, and even if they could communicate that complexety it would make no sense for them to do so, from a business standpoint.
so its basically impossible for someone who has not worked with it, to understand it.
i dont think he was talking about realtime lighting, because frankly every 3D engine has that.
as to enlighten; its a pretty complex technology, and even if they could communicate that complexety it would make no sense for them to do so, from a business standpoint.
so its basically impossible for someone who has not worked with it, to understand it.
I think Claydough missed the part where we all realized that Tan seemed to be mixing up realtime lighting with realtime GI.
No mate, sorry but I wouldn't confuse things to such an extent
In fact what I had asked for was " if there was any intel anyone has on new engines would become available to public like subscrption/ SDK". Then suddenly things started to jump around so fast I even forgot my own name for a second.
I don't want to go back to that part of the arguement and people who have hand on experience are actually writing so let's not go back to that
@ lnpw
Sage advice eh ? I will keep that in mind. Thanks mate
its not bad, its just very far from a "make GI now"-button.
i probably signed something somewhere that im not allowed to talk about all this in more detail.
its not bad, its just very far from a "make GI now"-button.
i probably signed something somewhere that im not allowed to talk about all this in more detail.
Interesting! I wonder if this is true in all licensed implementations?
Or did they just cripple support for dynamic skeletal geometry after the pre-release?
( for instance... after the posted 2008 pre-release demo which
seems to clearly suggest GI illumination on the character geometry driven by a movable light no less?? )
In case you guys want to try out this early version. This is like step 1 out of 10 toward getting it usable, but the scariest part is working (efficient indirect shadowing).
Change 2390645 by Daniel.Wright@DWRIGHT-Z2430-UE4 on 2014/12/16 19:59:21
Distance Field Global Illumination first working version
* Requires a Movable Skylight + 'r.DistanceFieldGI 1' + 'r.GenerateMeshDistanceFields' project setting enabled
* Provides a single bounce of Diffuse GI with bounce distance limited by OcclusionMaxDistance (default 6m)
* Virtual Point Lights are placed from the directional light by ray tracing the scene's distance fields, normal comes from SDF gradient
* Currently only placing 128*128 VPLs up to 40m from camera
* VPLs light irradiance cache samples using hemispherical disk light model, indirect shadowing is provided by the same cone traces used for Distance Field AO
* Irradiance is computed only at irradiance cache points (max every 8 pixels) and interpolated to the rest of the pixels
* Hardcoded half grey material color for now, and poor performance due to brute force VPL lighting
Replies
KISS version should be...
If you r that inspired by GI, as an artist that interest usually always is rewarded by artistic growth. Go fer it.
http://www.youtube.com/channel/UC0gLhZYuB4zofX0jpvVv6ZA
http://i.imgur.com/Wc8S1Ce.jpg
That is a very loose and misleading definition of Enlighten's GI approach
Thanks man. I am not as experienced as you but let me put a "my feelings exactly" here.
Thanks for sparing time to write all this.
Inpw
Yeah lookin col mmate. Do you guys have any problems in performance when nay units go at each other in the ame screen ?
marks
Yeah, I remeber it is not "baking" exactly but it is something like a "precomputing" thing.
All I know is I played a game made with Enlighten and it nearly killed my machine (PC). But then again maybe it was havingperformance issues that are soled today ?
Wow ! That much ? Hmm I must look on this subject.
It does still require baking though - it's not on the fly and doesn't work with non-static geometry
I can understrand need for dynamic GI in something like sandbox RPG, for that matter any sandbox game, as they tend to pretty open ended and dynamic in their own way, where nothing is set in stone.
Plus, players are usually quite close the the environment (FPP or TPP).
But RTS ? Camera is on top, and most players would be more than happy to put in even higher and replace all units with moving icons. Just sayin. That's how I'm playing Planetary Annihilation ;p.
Even fairly unit centric games like Dawn Of War 1/2 won't benefit much from advanced lighting.
Besides that simple bouncelight fakes can be integrated via ambient cubemaps, which are a a lot lighter than realtime GI.
claydough: nobody says that realtime GI is a bad thing, and it will come, no question about it. And it will be used where it makes sense, and possibly everywhere at a time where the computation costs can be ignored. But we are far from that point.
I was thinking about writing this last paragraph with a heavy german accent in it, to illustrate how hard it is to follow you thanks to your written dialect, would be really cool if you could drop it, just for the sake of readability.
Also, you can tell who in this thread has actually used Enlighten based off of how jaded their replies are. :-(
i dont think he was talking about realtime lighting, because frankly every 3D engine has that.
as to enlighten; its a pretty complex technology, and even if they could communicate that complexety it would make no sense for them to do so, from a business standpoint.
so its basically impossible for someone who has not worked with it, to understand it.
Tl;dr
It's THATTT BAD ?
No mate, sorry but I wouldn't confuse things to such an extent
In fact what I had asked for was " if there was any intel anyone has on new engines would become available to public like subscrption/ SDK". Then suddenly things started to jump around so fast I even forgot my own name for a second.
I don't want to go back to that part of the arguement and people who have hand on experience are actually writing so let's not go back to that
@ lnpw
Sage advice eh ? I will keep that in mind. Thanks mate
its not bad, its just very far from a "make GI now"-button.
i probably signed something somewhere that im not allowed to talk about all this in more detail.
Interesting! I wonder if this is true in all licensed implementations?
Or did they just cripple support for dynamic skeletal geometry after the pre-release?
( for instance... after the posted 2008 pre-release demo which
seems to clearly suggest GI illumination on the character geometry driven by a movable light no less?? )
[ame="
And if they did cripple suppport fer as much...
What hardware in 2008 did this demo run on?
Thanx in advance fer any illumination on the matter ( sorry, pun intended
https://forums.unrealengine.com/showthread.php?2421-Global-Illumination-alternatives&p=193884&viewfull=1#post193884