Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: pecenipicek on April 28, 2009, 05:39:36 am
-
I've been toying with this for a long time now, and i'm wondering, which things does the underlying OGL code expose? I've noted that i've been unable to appropriately implement anything even reminiscent of self-shadowing -.-
In any case, my idea for the implementation of shadows is something similar to Carmack's Reverse, with the shadow volume being capped in the distance of say 500m ingame, depending on the size of the shadowed object....
Since i'm obviously too dumb for things like pure OGL code, i've been trudging through the GLSL trying to figure out something worthwile... Anyone care to help?
-
i can't help you anyway i don't know anything about coding, but i just post to support you !
I wish you success!
-
You may be able to get something going with steep parallax mapping, however the performance hit might be pretty extreme. I'm not sure how else to get a decent effect with the current code though.
The current code was always intended to primarily be a place-holder/research-aid in order to work out what would be needed to add proper shader support in the future. So what's there now is really just a shader version of the fixed-function pipeline, with all of the same basic limitations. Somebody else might have an idea that could get it to work in pure GLSL, but I can't think of anything that would be remotely acceptable without a lot of code changes to get it working.
-
time to dig into the OGL then :p
can you atleast tell me exactly which shaders are used on following settings
ship lab:
no diffuse, no spec, no normal, no env, no glow
only diffuse enabled
I cant seem to really isolate a single shader file with which i might test properly. basically, i'd need some more detailed guidelines...
-
Isn't there another thread and now a wiki page with all of this information? I don't know the links though.
-
yeah, there is, and if you remember, i participated in that discussion, tho i still havent isolated the ones where i can actually see any change, so yeah, help from the man who made them would be appreciated.
-
no diffuse, no spec, no normal, no env, no glow
Should be l-v and null-f (no maps, only lighting).
only diffuse enabled
Would be l-v and lb-f (assuming lighting, otherwise null-v and b-f).
-
tnx.
i thought i was doing something wrong... damn... hmmmm...
the fun part? for example, in the shader designer i can see the rough effect of my code. in the ship lab, i fail to see any change at all. Does the usual folder hierarchy (ie. fs2/data/ dirs trounce mod folders and built in vp's?) apply to sdr files too or?
-
When I was working on that stuff originally I just made mod folders for testing different shaders. So if I was you I would create a "shadows" mod and put the shader files that you are working on under data/effects/ in that new mod directory. Then just put "shadows" first in your -mod cmdline and that way you will always know that you are working with the files that you want to use.
-
tnx :)
-
where in the code can i find the data that reveals what does OGL code expose to the shaders? I've been rummaging about now, and its kind of hard to find...
-
The uniforms that it uses are in gropenglshader.cpp (big array near the top of the file). Beyond that and a few of the built-ins needed to render, nothing else gets exposed. It really only offers the basic settings/functionality that the fixed-function pipeline uses too.
Is there something specific that you were looking for?
-
i've been looking to analyze the code exposing to see what i can actually use to get the needed data for the bloody thing...
after further research, i need to either get the stencil buffer out to the shaders, or something like that... after 3-4 hours of researching through ****, i'm at a loss... i'll work out something, could you just direct me to the part of the code that deals with depth buffers and in general framebuffers?
[edit] after some thinking, i believe that doing it via shadow volumes would probably be the best option... ( http://en.wikipedia.org/wiki/Shadow_volume )
My proposal?
Get the engine to actually do the damn thing :p
(no, its not a feature request, its more of a "point me to the relevant blocks of code and i might do something proper for a change" :p )
It might be worth to explore this problematic further....
-
Careful, apparently some of those techniques are patented (http://en.wikipedia.org/wiki/Shadow_volume#Depth_fail).
-
i'm quite aware.
we'll find a way around. probably something unrelated to the shadow volumes. we'll see how the engine reacts once i actually get to working code.
-
You don't need shaders for Carmack's reverse. Actually that way of producing shadows is rather simple (as long as you stick with a single light source, like a nearby sun), and I guess that in space you wouldn't even need to have soft shadows.
-
Yeah I pondered the need for soft shadows for all of .03 seconds before realizing it would be a seriously wasted effort.
-
It wouldn't be wasted effort because sun is not a point source of light (although they behave as such in FreeSpace) but a disk. Softness in shadows isn't caused by the atmosphere; ambient light from scattering is a different matter altogether. All shadows have umbra, penumbra and antumbra, and that includes the shadows cast by objects in space. The "blurry edge" of the shadow would be defined by the angular diameter of the light source and the distance of the shadowed object and shading object.
Of course, for general purposes simple stencil shadows would be well sufficient and much better than no shadows at all. But in capital ship scale, shadows would definitely have a degree of blur on their edges. But I would not call soft shadows a wasted effort by any means - if someone can implement a solution that doesn't tax the computer impossibly much.
-
You are wrong. The blurred borders of shadows are caused by scattered light, and so are penumbras - these appear when shadows from several light sources (or a big one) that are lit by ambient light overlap. In space you have no scattered light and only a single light source, and if the sun is sufficiently far away, it is close to an ideal point. Just google for some photographs of space stations orbiting the earth, or the Lunar lander: http://scienceblogs.com/gregladen/images/Surveyor_NASA_lunar_lander.jpg , http://www.lpi.usra.edu/expmoon/Apollo11/A11_LanderFS.gif
If you wanted a perfect solution, you'd take light reflected by ship hulls into account ... but then we're talking raytracing already.
-
No, I am in fact not wrong.
The half shadow phenomenon is caused by the fact that sun is not a point source of light. The light passing through the atmosphere of Earth has a different effect, as the red light passing through and refracting and dispersing causes it to light objects in the shadow of Earth and this effect colours the Moon copper-shaded. But the geometry of shadows in space (or anywhere) is not in any way dependant on atmosphere. The shadow cast by the Moon has the exact same geometry that accounts for different kinds of solar eclipses.
The bigger the apparent diameter of the light source, the faster the shadow edges grow blurry. This image should clear it up nicely:
(http://upload.wikimedia.org/wikipedia/commons/2/2e/Diagram_of_umbra%2C_penumbra_%26_antumbra.png)
Or in scale:
(http://upload.wikimedia.org/wikipedia/commons/5/5b/Earth_umbral_cone_(partial).png)
You can see the shadow's edge getting much less defined as the distance increases, and it has fundamentally nothing to do with the atmospheric scattering.
The reason for shadows appearing so sharp and defined in space photography is because they are precisely that - at the scale that they are photographed. The length of the shadow is simply short enough that the shadow's geometry doesn't play an important role in it. Which is why I said that for general purposes, a stencil shadow system would be largely sufficient. Especially for self-shadowing of ships that are sized similar to, say, the Space Shuttle Orbiter and smaller.
But things like the Colossus are several kilometres long. At this kind of distance, some softening on the edges of the shadows would definitely happen already (depending on the apparent diameter of the light source of course). Not to mention stuff like casting shadows on other models, in which case the distances can be even larger and soft shadows (if accurately depicting the umbra/penumbra phenomenon) would definitely be beneficial to realistic lighting.
But like I said, stencil shadows would be "close enough" for most cases and definitely better than the complete lack of shadows that we have right now. :)
EDIT: And while it is true that far enough from the star it would appear close enough to point source of light, who says you'll always be that far from it?
You could have a situation where a red dwarf or red giant has a lot bigger diameter than our Sun at one AU distance (about half a degree). Or you could have a situation where the apparent diameter of the star is so close to point that it doesn't matter in the distances involved in FS2.
However, a stencil shadow can only deal accurately with the latter optimal scenery, while if the shadows were more accurately modeled, same system could obviously deal with both cases. It would "just" require a definition of the apparent diameter of the star's disk in mission background information. And of course a working system that correctly implements umbras, penumbras and all that jazz...
-
I admitted that you'd have a penumbra with a real big light source, but you won't have soft shadow edges in space. Apart from that you cannot prove your point by using the moon as an example, because the target environment is spaceships in space, and probably in quite a distance from a sun. Finally, your sketch is grossly disproportionate. We're talking about 150 million km distance between sun and moon, compared to the sun's diameter of around 1.4 million km and a moon diameter of about 3474 km. What fraction of the moon's size is even the biggest ship from FS or FS2. Your argument imo is completely pointless given the scale of the shadow casters in FS.
-
rule of cool my man, rule of cool...
about shadows in space.. -.-
http://thebloatedbrain.files.wordpress.com/2009/01/space-shuttle-challenger.jpg
http://www.spaceline.org/rocketsum/images/bigshuttlechron.gif
take it as you wish, hard shadows first, soft shadows, maaaaybe. :p
-
If we're going to get scientific about it, that far from the star, you wouldn't get the level of ambient lighting you do in Freespace in the first place, and if there was that level of ambient lighting, then softening on the edge of shadows would be inevitable because light would bleed in from reflected sources.
-
How about we get any semblance of a shadow first, before we start arguing whether to make it hard or soft? Code whichever one is easier, and tiny details like how fuzzy shadows can be can come later.
-
And deny people the right to yell at each other in the name of science for 3 pages? ;)
-
definitely.
-
On HLP?
-
On HLP?
No yelling at each other over science ( physics, etc...) on HLP please, that's what's Game Warden is for...
*checks GenDisc...
...only yelling at each other over religious stuff seems to be allowed... :nervous:
:p
-
Meh, you should hear the 'there's no sound in space' discussions ;)
Actually, a lot of that religious stuff involves science, since that is the usual 'opposition' to religious viewpoints.
-
Meh, you should hear the 'there's no sound in space' discussions ;)
Actually, a lot of that religious stuff involves science, since that is the usual 'opposition' to religious viewpoints.
Yeah, but in that case science is only a tool to disprove arguments on the subject ( religion ), not the subject itself. :)
Ah, i miss the endless debates about physics in real life, movies and games..., maybe i should post a totally absurd assertion and see what happens... :D
-
Mods, please remove all the unrelated posts....
-
No. :p
At the moment, we are waiting for news, if the chatter continues when there's actually stuff to discuss, then I'll consider splitting the thread, until then, it's not out of hand, and it is, strangely enough, still remotely connected to the discussion of the behaviour/science of shadows, so it doesn't need to be removed.
Edit : Especially considering it's the grand total of about 3 posts that would even remotely fall into the 'unrelated' category, and one is from me, and another is from you.
-
...could you just direct me to the part of the code that deals with depth buffers and in general framebuffers?
There isn't any such section of the code really, not anything that deals with the scene in any way that you need at least. The FBO code is just the most basic implementation possible, and is coded only so far as to get basic textures from (ie, no depth info). You could possibly modify the existing FBO code to be used (with even more modifications) to do what you want, but you would probably be better off just duplicating some code and make new functions that deal with proper rendering effects as opposed to just getting 2D textures. Depending on exactly what method you use to get shadows it might take some rewriting of the model/object rendering code as well to do what you want.
-
i'm gonna delve into this **** now... hopefully i'll have something standalone to show soon...
i just hope i dont crack before i manage to do it.
-
I admitted that you'd have a penumbra with a real big light source, but you won't have soft shadow edges in space. Apart from that you cannot prove your point by using the moon as an example, because the target environment is spaceships in space, and probably in quite a distance from a sun. Finally, your sketch is grossly disproportionate. We're talking about 150 million km distance between sun and moon, compared to the sun's diameter of around 1.4 million km and a moon diameter of about 3474 km. What fraction of the moon's size is even the biggest ship from FS or FS2. Your argument imo is completely pointless given the scale of the shadow casters in FS.
No, it isn't pointless. The proportions of the shadow would be pretty much same for a much smaller than Earth object. The lower image was in scale.
With a very simple application of geometry you can calculate the length of the umbra for objects of any diameter. If D is diameter of light source, d is diameter of object, L is distance to the light source and l the length of umbra cone, you get
l = d*L / (D - d)
For objects with d<<D, it can be said that D-d = ~D and therefore approximated that
l =~ d*L / D
Using values
L = 1 AU = 149 598 000 000 metres
D = 1 391 000 000 metres
d = 100 metres
we get umbra length of approximately 10.8 kilometres. That's the distance to the tip of the umbra.
Similarly, the width of penumbra at any given length = l can be calculated by
P = d + ( l [D+d] / L )
Calculating for example with diameter of Sun, distance 1 AU, and penumbra width at 1000 metres behind the object... the penumbra width shows 109.298253 metres.
For example, an object with hundred metres diameter would have an umbra with length of roughly eleven kilometres. Mind you, that's the distance to the umbra's tip itself; softness to shadows would appear much sooner. For example, at one kilometre from the object, the umbra is roughly 91 metres wide and penumbra is the aforementioned 109 metres. That's an 18 metres wide gradient area at the edge of the shadow.
Considering that for example Colossus is about six kilometres long with that fancy structure in the middle, it could conceivably cast a three kilometres long shadow on itself. That means almost sixty metres of blur on the edge of the shadow already. Very much noticeable compared to sharp edge of a stencil shadow if you're flying next to the ship.
Also, capital ships casting shadows on each other could very well have even longer distances... so no, I don't think it would be waste of effort putting accurate soft shadows in. It would be noticeable in certain situations.
Of course this is all being calculated with a sun with apparent diameter of half a degree... if teh sun is larger, the difference would be even larger. And considering how unfathomably unrealistically big FreeSpace suns tend to be... why not apply the same to the shadows? It's not like realism is the highest authority regarding FreeSpace stuff anyway.
After all, if the shadow code is done right you should be able to specify the apparent diameter of the light source in the mission background editor, or something equivalent. A very small diameter would result in a very stenciley effect, while larger diameter would result in softer edges on the shadows. That way it would be up to mission designer to specify the lighting conditions in this sense; if someone wants sharp shadows and realistically small sun they can do it, while the engine still can do soft shadows in situations where the suns are really big - like in retail FreeSpace campaign, for one good example.
But I feel we're skinning the mammoth before it's taken down here. There are no shadows in the engine yet... and stencil shadow would undoubtedly be simpler to utilize, so I would be more than content with that, at least to begin with. Any shadows would be better than none at all - and I do admit that in vast majority of situations, there would not be perceptible difference between stencil and soft shadows. :)
...holy scheiber, nine new replies. :eek2:
-
Mods, please remove all the unrelated posts....
Got your notification....but I had a read through the post and its pretty much all on topic. Maybe two or three that I *could* remove but then the subsequent comments make less sense and disrupt the flow of conversation. They can stay. If things get really out of hand that would be a different story.
-
That was my opinion too, hence why I decided not to split it yet, if we split out every off-topic comment in every thread, we'd never get anything else done.
-
you may still want soft lighting in the nebula and other atmospheric conditions. just because the retail game takes place in space doesnt mean modders wont pull some tricks and come up with something completely different.
-
There are soft shadows in space. However there's no way in hell you'll get soft shadows before stencil shadows, so the point is mute. Also, realistic shadows in a nebula would have tons and tons of problems, especially due to the fact that the nebula is lit from all sides, so I would recommend just using very light shadows in that case or you'll die trying to figure out what the heck shadows look like in a nebula.
I would like to mention that the patent application seems ridiculous. I looked at the z-fail situation and was like "WELL OF COURSE IT WORKS IF YOU REVERSE THE DEPTH!" It seems like a painfully obvious thing to me, and this is supported by the fact that one smart dude at id software figured it out on his own, but whatever.
-
Harra,
Your kind of over-educated perfectionism kills every advance in a project like this one because it leaves feasibility out of consideration for the sake of covering anything to the greatest extent.
Did you see a penumbra or a soft shadow in the photographs I supplied? I can't remember having seen one in skylab photographs either. Shadow edges look razor sharp there.
But go ahead and code shadows with penumbra and soft borders. Good luck. I am looking forward to what you will come up with. Stencil shadows on the other are easy enough to do (even with penumbras, but not with soft shadowing).
For me this is exaggerated perfectionism turning me off from wanting to help out with this (or smoke, or per pixel lighting with speculars, bump and parallax maps).
blackhole,
No soft shadows w/o diffuse light. No diffuse light with something scattering it. Nothing there to scatter light in empty space. As far as the nebula go: Just because they appear as colorful, dense clouds in a telescope doesn't mean they're like that in space. Afaik they're extremely thin concentrations of glowing plasma or gas, so actually a huge light source themselves, which would mean no shadows in a nebula at all.
So yeah, that's what I could add to FS and FS2:
- A fast particle system creating nice smoke trails for missiles (if you haven't done so already, check out my video in the "Smoke?" thread ;))
- Stencil shadows for space vessels (afaik not patented, and everybody and their dog uses or used it)
- Per pixel lighting, allowing bump or parallax mapping and producing nice speculars on reflective surfaces
What I also have is very fast 3D model rendering code and a means to convert various model formats (POF, OOF, ASE) into it. That code will speed model rendering up by at least a factor of 4 compared to vanilla POF model rendering.
I'm pretty much done with D2X-XL, but using some stuff I have learned while building it in another project seems attractive to me.
On a side note: Do FS/FS2 use FBOs?
karx
-
Calm down karx11erx. HT has already said more than a couple of times that he considers stencilled shadows a huge improvement on the current code. And I doubt he'd complain much if the game code never went beyond that.
You have to differentiate between the scientific argument and the what should be done to the game engine argument.
-
What he said.
Stencilled shadows would be awesome, soft shadow possibility even better, and considering there are quite a few mods that involve or are planning to involve atmospheric missions (Shadows of Lylat, 158th Banshee Squadron, probably Diaspora, even retail FreeSpace 2 nebula missions) it wouldn't be wasted effort. Just possibly excessively awesome considering the implementation of soft shadows would also work if you wanted stenciled shadows, but stencil shadows wouldn't work if you wanted to have soft shadows.
And like you would have noticed if you read my messages thoroughly, the shadow edges on the photographs of our space ships don't show soft shadows, because the spacecrafts are so small and distances so short that it really doesn't start showing on the photographs. Self shadowing of fighter/bomber sized ships would look pretty much like stenciled shadows for obvious reasons, but remember that an Ursa is already larger than the Space Shuttle Orbiter, and we haven't built six kilometres long warships so showing images of Skylab or the Orbiter isn't really relevant on how shadows would look on that kind of behemoths...
Also, regarding perfectionism, I refer you to my recently aquired user title. :p I do think that if possible, modeling things as accurately as possible will be more beneficial in the long run, even if technically easier but more crude way would suffice for current purposes. That's why I think that if feasible, soft shadows wouldn't be wasted effort. If it's not feasible, then stencil shadows are just fine and dandy. But I am not a coder so I wouldn't know how much more difficult it would be to make the shadow geometry realistically defined by the apparent diameter of light source. Probably a lot. :D
Stencil shadows with ambient occlusion would probably make me defecate ceramic building materials right there, I don't know what soft shadows would do... :lol:
-
No soft shadows w/o diffuse light.
Fine :C
As far as the nebula go: Just because they appear as colorful, dense clouds in a telescope doesn't mean they're like that in space.
Quite true. However, FS2 doesn't care what they're supposed to be like.
I do think that if possible, modeling things as accurately as possible will be more beneficial in the long run
Not in programming. Rendering something with stencil shadows and rendering something with soft shadows requires 2 very different approaches.
-
I do think that if possible, modeling things as accurately as possible will be more beneficial in the long run
Not in programming. Rendering something with stencil shadows and rendering something with soft shadows requires 2 very different approaches.
Hence the disclaimer "if feasible".
-
Calm down karx11erx.
I would sound pretty different if I wasn't calm. Let's just say that I occasionally tend to express my opinions in a rather pointed way. Don't over-interprete it. ;)
Also, regarding perfectionism, I refer you to my recently aquired user title. :p
Yeah, I had noticed it and have had my thoughts about it already. :P
Stencil shadows are cheap performance wise, particularly in an environment as FS with no static geometry (only objects). Soft shadows are costly. Depends on what class of machines you want to be able to have shadows on ... ;7
-
karx11erx, want to help out with implementing the damn thing then?
as for my understanding of soft vs stencil only, its hard to get the former without the latter :p
also, soft shadows can be made via shaders, taking the data stencil shadows give and fuzzyfying the edges with the likes of gaussian blur and stuff. (probably not exactly gaussian blur, but you get the idea....) i think.
-
Provided FS(2) is using FBOs as render targets, making soft shadows from stencil shadows and blending them into the final image shouldn't be too hard.
Before I start to implement stencil shadows, I first need to understand the model renderer and probably replace it by a better one (as I said: I have written a pretty well optimized model renderer for D2X-XL using VBOs that understands POF, OOF and ASE formats). That would be both beneficial for FS and make it easier for me to add stencil shadows as I know my own code pretty well. ;)
I have read that FS2 open already uses shaders and I need to find out how and to what extent. I don't know e.g. whether it already uses per pixel lighting. If not I could add that, and in a subsequent step we could implement bump mapping to give the ships more detail at little extra cost (would require somebody to create bump maps for the ship textures though).
Another thing I'd really like to see are smoke trails for missiles. These are easy to implement and really give an entirely new dimension to a game like FS because they add a real sense of depth and distance to huge scenes like those in FS.
I am currently having a problem with checking out the source code from the SVN repo (svn://svn.icculus.org/fs2open/trunk/fs2_open). Either I get a gateway error (#502) or a message that icculus.org doesn't respond. :(
-
...
bump maps are kind of irrelevant and completely redundant when we have normal maps....
as for the errors in the svn, check your router is my first hunch...
-
Well, I can access the D2X-XL SVN repo on SF.net, but icculus.org doesn't respond ... can be the network I am in, or icculus.org - can't tell from here. I will retry later.
Are your normal map vectors in object or tangent space?
-
I am currently having a problem with checking out the source code from the SVN repo (svn://svn.icculus.org/fs2open/trunk/fs2_open). Either I get a gateway error (#502) or a message that icculus.org doesn't respond. :(
That is strange. It's working just fine for me, just tested it now. Does the web access (http://svn.icculus.org/fs2open/) work for you?
-
Forget it. Maybe it's the network firewall here.
Still need to know whether the FS normal maps are in tangent space ... and need to fully understand tangent space calculations ... http://www.3dkingdoms.com/weekly/weekly.php?a=37 ?
-
tangent space.
-
Stencil shadows are cheap performance wise, particularly in an environment as FS with no static geometry (only objects). Soft shadows are costly. Depends on what class of machines you want to be able to have shadows on ... ;7
There is also stencil shadow method which produces very realistic soft shadows with realistic umbra/penumbra and it has a free source code.. ;)
http://graphics.cs.lth.se/research/shadows/
-
[Bookmarks those links for the day he can understand the math]
-
i can't help you anyway i don't know anything about coding, but I love the idea of having real shadows in game!
This feature will be amazing :)
Good luck!
-
/me sides with Herra on the 'realism' debate, and karajorma on the 'feasibility' aspect.
-
back to nebs i think self shadowing in the nebula would be awesome whenever a lightning bolt goes off. even if the shadow is well lit because of ambient light, it would still look pretty cool to have the exposed side brightended and to show some lines.
as for smoke i think implementing it in a space engine would be more difficult than in d2xxl, because of the longer distances the trail must travel. for it to look good you would need to render a great deal many more sprites. this is evident in my particle build. while my high level code allows you to construct some interesting effects, the pre-existing low level code is just too slow to handle it.
-
I wonder, what if you grouped the emitted smoke particles by when they were created, by when they were emitted? In theory, they should all be close together, so you could cull entire groups of particles before determining which particles in the group need to be drawn.
-
thats kinda how my helical trail works. the code figures out how much of the trail to create, then creates those particles. actually i think that slows things up abit. theres also a bug where if you dont release particles every frame that youl get gaps. if i fix that bug then that type of trail will work better. for smoke you would use more of a simple trail with a few particles created every frame. with a short enough lifespan particles will be removed. trick is to strike an equilibrium between particle creation and removal. its currently very easy for a moder to create way too many particles and overload the system.
theres also issues with fadeout. particles just dont, unless you animate them. but that creates other concerns. id like paticles to either fade out over the particles whole life span or part of it to smooth out the deletion of the trail. perhaps even make it possible to get rid of the bitmaps as well (rgba particles) if it improves perfromance. treat particles as primitives rather than sprites.
-
:bump:
(I'd love to see shadows in FS!!)
-
per pixel lighting with speculars, bump and parallax maps.
Well, that part is done. :-D
-
Ambient occlusion for nebula missions can be precomputed. And stored as an ambient light map, which adds to the diffuse lighting. Alternatively the diffuse could already be baked into the ambient light map. (only works with original texture coordinates) (popably not good for most models for that reason) (especially not for capships which use tiling)
-
Actually, quite a few ships use AO bakes in their diffuse textures now, I know a lot of recently made ones do.
-
Albedo or diffuse map should not be combined with ambient occlusion map as it makes the result look muddy. (meaning multiplying ambient on top of diffuse into the RPG channels.)
The problem is that previously white surface is now dark gray in direct light, same happens to all colors.
Ambient occlusion should be it's own channel or channels which masks ambient light. (Best result would be direction aware occlusion of ambient.)
-
Albedo or diffuse map should not be combined with ambient occlusion map as it makes the result look muddy. (meaning multiplying ambient on top of diffuse into the RPG channels.)
The problem is that previously white surface is now dark gray in direct light, same happens to all colors.
Isn't that only when you apply the AO bake to the shinemap?
-
Albedo or diffuse map should not be combined with ambient occlusion map as it makes the result look muddy.
Yes. But that's common practice at the moment. Ambient occlusion is for ambient light, meaning non-directional. Like light from a nebula. The diffuse map shouldn't contain ambient occlusion, as that reduces the quality of direct light computations. (sunlight)
The only case where nebula light is directional is when you are close to some big object, which blocks the light.
If the move to adding support for seperate ambient oclusion maps in the engine is somwhere in the future, modelers should at least keep the maps seperated somewhere on their hard drives, so they can be added later. Or the mvp team can store them somwhere.
The other thing is that, for artistic reasons, a lot of modelers propably want ambient oclusion on their ships even for missions which don't take place in a nebula.
Something else: Why don't we have specular power maps?
Isn't that only when you apply the AO bake to the shinemap?
Why should anyone add ambient occlusion to the shinemap?
-
Isn't that only when you apply the AO bake to the shinemap?
Why should anyone add ambient occlusion to the shinemap?
Actually, I'm not sure that sounds like a horrible idea. I'm curious how that would come out.
-
i find it bizzare how uneducated the last few posts have been on the usage of pre-baked AO and the usage of it in the context of texturing and the limitations of that particular technique.
also, i find it bizzare that this thread of mine resurfaced after almost a year of stagnation...
-
Year of stagnation? Does that mean that you haven't had the time to make some headway into this? That's unfortunate :(
And yeah, some of the above AO comments read like something off of yahoo answers...
-
I don't think pece is a coder.
-
nope. i was trying to figure out heads from tails for that and failed miserably, and just let this slide. i fail as a coder, but i do okay as a modeller. so yeah.
-
i find it bizzare how uneducated the last few posts have been on the usage of pre-baked AO and the usage of it in the context of texturing and the limitations of that particular technique.
Are you talking about my post? Would you care to educate me?
I should add, that my comment was not about using ambient occlusion to visualize detail that is only on the texture. I was talking about using it to reinforce the appearance of geometry which is modeled with polygons. With techniques like horizon mapping and normal mapping things are different of course.
-
This reminds me, has anyone tried to simulate a light coming from glowmap with proper GI and output it as a glowmap?
This is something that multiple UVs would help a lot, but with unique texturing for a ship it can already be tested.
This is a trick that wouldn't cost anything(outside a UV), but would give a nice shape and give a feel of local lights and interreflection to the ship.
Something like volume PRT vould be a nice way to do this and inter reflection to other ships, but it would require some deep planning and rewrite of code. (directional (5d?) texture on octree is a funny thing.. ;))
-
This reminds me, has anyone tried to simulate a light coming from glowmap with proper GI and output it as a glowmap?
*points at the iceni in the most recent MVP's*
-
HTL Hattie is also an example of this.
-
Nice.. need to check them out. :)
-
What about straightforward shadows? Not rushing or anything ... ;)
Like global warming campaigners say, "no pressure" :p
http://www.youtube.com/watch?v=sSTLDel-G9k
-
Straightforward shadows as opposed to what?
-
any upgrade regarding shadows?
-
nope. the coder, who's supposed to work on it, hasn't joined yet, thus he/ she hasn't started to work on it.
All other coders have other stuff on their plate.
-
What about straightforward shadows?
not availible yet. and the glsl implementation needs some base shadow stuff to work on before it gets to the GLSL stuff.
-
What about straightforward shadows?
not availible yet. and the glsl implementation needs some base shadow stuff to work on before it gets to the GLSL stuff.
Which reminds me, FS2 has huge amounts of empty space and no ground in it's most basic setting.
This should give some nice options in terms of how to do the shadows.
IE. finding shadow receivers against FoV, then in lightspace find casters which actually can shadow any of them. (compare bounding boxes/balls and create shadows which can actually be visible.)
IF one doesn't want selfshadowing the amount of actual shadows drop basically to nothing.
Biggest problems should be the shadow resolution with shadow maps are used and volume generationd and fillrate when using shadow volumes.
Both are interesting 'little' problems, which happily get easier in a scene full of nothing.
-
IF one doesn't want selfshadowing the amount of actual shadows drop basically to nothing.
I think that self-shadowing is the first most important thing... those ships still don't look realistic *only* because of self-shadowing.
-
Self-shadowing would indeed make a huge difference.
-
I disagree. Lighting in FSO (especially with the newer fragment shaders) is already pretty decent. What we need is occlusion shadowing.
If I'm on the dark side of a ship, I shouldn't still be as fully lit as if it's not there. I don't care about whether or not my wing cast a shadow on my canopy at the right angle to the sun.
-
I'd like to see both self shadowing and occlusion shadowing, I think that the first one to be implemented should be the one that could be implemented faster and with less work.
-
I disagree. Lighting in FSO (especially with the newer fragment shaders) is already pretty decent. What we need is occlusion shadowing.
If I'm on the dark side of a ship, I shouldn't still be as fully lit as if it's not there. I don't care about whether or not my wing cast a shadow on my canopy at the right angle to the sun.
Nor do I, but I do care when I see big warships illuminated without shadows. It's completely unrealistic. If you guys are ever able to implement this, you will understand the difference. Heck, one could even discard the fighters' shadow completely and focus on the big warships.
Occlusion is nice but not as distracting. I'd approve of it as well ;)
-
Occlusion shadowing as self-shadowing (if it can be used that way) would work nicely for something like an Orion, but there'll be troubles with ships like the Hecate or Ravana.
-
I disagree. Lighting in FSO (especially with the newer fragment shaders) is already pretty decent. What we need is occlusion shadowing.
If I'm on the dark side of a ship, I shouldn't still be as fully lit as if it's not there. I don't care about whether or not my wing cast a shadow on my canopy at the right angle to the sun.
Nor do I, but I do care when I see big warships illuminated without shadows. It's completely unrealistic. If you guys are ever able to implement this, you will understand the difference. Heck, one could even discard the fighters' shadow completely and focus on the big warships.
Occlusion is nice but not as distracting. I'd approve of it as well ;)
looking forward to your diff
-
Occlusion shadowing as self-shadowing (if it can be used that way) would work nicely for something like an Orion, but there'll be troubles with ships like the Hecate or Ravana.
Light occlusion is shadowing, you guys should be more clear about what you talk about. (ambient occlusion is shadow for a light which comes from every direction.)
If you mean with occlusion a method which produces a inperfect shadowing in terms of accuracy and hope that it doesn't look too offending, there are several although non proved ways.
Most of them have problems in terms of asset generation and/or rendering.
Something like low-res volumetric distance field for each ship could do the trick.
Basically one would trace against it and see if the light is behind something solid, as it is distance field one would have acceleration structure and ability to change the blurriness as well.
It would not be accurate, but it would give general sense of shape.
Shadows from other ships could be done as drop down shadows, but as always with combination of different methods a shadow mask buffer is a must for this. (render shadows to buffer and then use it to occlude the light.)
Here's couple of links to distance fields.
http://hyperfun.org/FHF_Log/Bastos_GPU_ADF_SMI08.pdf (idea of using distance fields for an object representation, we do not need nearly as high resolution.)
http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf (valves distance field text rendering.)
-
Looking forward to your code then.
-
Looking forward to your code then.
My main reason to post previous post was to show how hard is to get a blobby self occlusion, which most likely wouldn't have temporal problems or bad surface acne.
I'm not certainly saying that those would be anywhere feasible methods when comparing to traditional shadowing, nor that I have capasity to do them. (no, you really do not want me to mess with the codebase..)
There are plenty of different methods one can consider, but shadows are hard problem and 'simple occlusion' can seem easy problem until you start to think about it. (I have for several years as a algorithm/graphics enthustiac.)