Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Taristin on November 07, 2004, 10:07:53 am
-
Do any of the coders know anything about how to implement a normal mapping system?
I ask, because I just found that 3dMax lets me do a render to texture of a few different maps, including normals... and it could be interesting.
-
AFAIK the problem is the aditional render pass, which is not supported right now.
Or something like that. ;7
Edit: I think I just mixed something up. Not sure though...
-
The problem is that we have no ultra-high-poly models to get the normal maps from. Shrike or someone was working on an Orion(11,000 for one of the turrets), but that was years ago.
-
Normal maps could be useful in many places simply to smooth off curves, but TBH I'm not that fussed about their inclusion just yet. There're a lot more important things than yet another graphical enhancement IMO.
Except, I guess, overexposure. ;) :p
-
I know how to implement them; pixel shaders :)
-
I think bump maps would be better. Easier to create, less performace hit.
-
I am with Lynx...I have also asked for the implemention of such maps over at Sectorgames...after a long time I also thing that Bumpmaps are the easiest to create and less resources using textures we could/should have.
-
if u were that desperate for normal maps, u could make them urself - its not that hard.
what we dont need is more mb towards the allready big VP files.
for once - think about us 56 k'rs
-
I'l tell you what, we'll compromise. You go get a 128mb Jumpdrive and then go to the Public/College Library or Internet Cafe of your choice and download on a broadband connection. What is happening is FS2 is becoming an essentially new game, graphics wise, that is going to entail LOTS of new files eventually, which translates to high MB counts. The rub is that most of the members have sometype of BB connection access.
It is no longer a narrowband web. Contrary to what AOL preaches.
-
I am more concerned about functionality of fred2_open than adding any new features to fs2_open. Those who develop solely fs2_open, I wish they would have a short pause and optimize existing code to minimize resource usage and improve stability.
But I guess this is the trade-off of a fan based development community.
-
Originally posted by Bobboau
I know how to implement them; pixel shaders :)
I doubt most HLPer's GPUs support that, from what I've seen in the threads people post every so often
-
Originally posted by Bobboau
I know how to implement them; pixel shaders :)
It CAN be done without pixel shaders! Doom3 actually can do it without pixel shaders (which is why a GeForce4 MX can run Doom3, albeit very slowly and worse-looking than a PS 2.0 card).
If you don't believe me, look at the BumpSelfShadow example in the DirectX SDK, which uses Dot3 bumpmapping, and works without pixel shaders.
-
I'd rather see bumpmaps implemented first. They definitely don't require pixel shaders (and I'd like to see those implemented at some point too, although realistically it's probably never going to happen since few people seem to want them/are able to use them) and they still look decent.
-
$#@!!$#@!$#@!$#@!$#@!$#@!$#@!$#@!$#@
on any modern card,
Bump maps == Normal maps
-
Originally posted by Roanoke
I doubt most HLPer's GPUs support that, from what I've seen in the threads people post every so often
I think it's time to add pxiel shaders. As long as they are optional I see no problem in this.
Personaly I don't mind if there's an effect I can't use because my GPU is outdated.
My current GPU supports only PS 1.3. But I will upgrade. Add pixel shaders, so I have something to look forward to. :)
-
Pixel shaders could be used to solve most graphical problems people seem to be having. My Radeon 9000 wont display shinemaps and env, but ill be damned it dosnt render the pixle shaded version. If we use 1.1, most cards wont have a problem.
Also, alot of ATI and Nvidia drivers have boosted pixle shader performance, because of all the new heavy pixle shaded games out, like Halo, Far Cry, Doom 3, etc.
-
now all we need is someone who knows how to code pixel shaders, and knows how to make them work with the existing system!
-
Originally posted by Fry_Day
It CAN be done without pixel shaders! Doom3 actually can do it without pixel shaders
yeah, but it still needs vertex shaders IIRC
-
Well, as much as I'd love to see Bump/Normal mapping working on FS2, I think it's going to be a bit more than a simple job :(
Are you still hoping to redo the texture system Bobboau?
-
there's lots of stuff I 'hope' to do
-
One thing that Halo impresses me with was the use of one texture set. All those fancy graphics were done with one texture supplying all the needed data for spec, env, bump, and glow.
-
Halo or Halo 2? Halo 2 uses normal maps heavily.
-
halo 2 probably uses the same concept. Nobody has modded it yet.
a bump map is basically the same as a normal map.
-
Originally posted by Bobboau
yeah, but it still needs vertex shaders IIRC
yes, but unlike PS, VS are emulated very fast on modern CPUs. Code using Vertex shading is about the same speed as code using fixed-pipeline calculations doing the same operations on a CPU.
That, I tested.
-
but it will still reqire a VS infrastructure, wich is the tricky part becase we have a dynamic vertex format.
I'm thinking it might be a good idea to do this and the model reformat at the same time, we can add to the model format the vertex format (on a per buffer basis) it's going to use and add a vertex and pixel shader option.
-
I can cover the OpenGL side of matters there pretty easily, since the actual OpenGL calls are nonsense. Upgrading the infrastructure is API-independant anyway.
-
dooo eeeet
-
One small confusion regarding multi-layer textures.....
Supposing you had a texture that was 2048 x 2048 and you didn't want it to have a shine map. Now, in the current system, you can just create a little 16 x 16 black square and make that the shine map.
How would this sort of thing work in the new system, would it not use shine if you didn't include a shine-map in the texture, or would it use the colour as shine like it does now, which would mean that to not shine, I'd have to include a 2048 x 2048 layer of pure black in the texture file?
Does that make sense?
-
Oh, you mean, since the different image layers can be different sized, now, how could it be done in the future?
/me gets what you mean, but doesn't think he can type it any more effectively...
-
texture coordinates are relative, therefore, the texture size shouldn't matter.
-
So, assuming the technique being worked on is similar in setup to a .PSD file, i.e, one layer for each texture effect, glow, shine, bump etc, then these layers would be capable of being different sizes from each other in the same file?
-
Yup.
-
Cool! :D
-
Originally posted by Fry_Day
$#@!!$#@!$#@!$#@!$#@!$#@!$#@!$#@!$#@
on any modern card,
Bump maps == Normal maps
Not always true. Strictly speaking, bumpmaps encode only grayscale hight data. Normal maps however store X,Y, and Z normalized vectors in an RGB color format. Bumpmaps are not instrinsically made for smoothing surfaces and "faking" geometry as it were.
-
^yeah, normal maps are somwhat independant of surface normals, whereas bump maps are entirely dependant. Thus normal mapping is better for full UV mapped objects whereas bump mapping is more suited to tiled textures.
-
Originally posted by Sticks
Not always true. Strictly speaking, bumpmaps encode only grayscale hight data. Normal maps however store X,Y, and Z normalized vectors in an RGB color format. Bumpmaps are not instrinsically made for smoothing surfaces and "faking" geometry as it were.
What I meant is that internally you need to convert the bump map to a normal map anyway ('cause that's what Dot3 wants), so what does it matter what you call it?
-
True. I guess in that case it's more a semantic argument than anything else. :)
-
so are we gonna get em?
-
Such an implementation would be useless, unless someone will take the time to create the new textures. Using a photoshop manipulated texture original will not work well. Someone will have to literaly hand trace the parts have hieght differentiation.
In reguard to normal mapping, doesn't that require a high poly version of the ships for it to be convincing? So far there are only a handfull of those. That modeller would also have to create bumpmaps from scratch to make a goodlooking highpoly model that normal mapping would draw from.
-
: Looks at 1998 version :
: Looks at SCP and how much we've done so far..... :
Bring 'em on ;)
-
Originally posted by Omniscaper
Such an implementation would be useless, unless someone will take the time to create the new textures. Using a photoshop manipulated texture original will not work well. Someone will have to literaly hand trace the parts have hieght differentiation.
In reguard to normal mapping, doesn't that require a high poly version of the ships for it to be convincing? So far there are only a handfull of those. That modeller would also have to create bumpmaps from scratch to make a goodlooking highpoly model that normal mapping would draw from.
lightspeed will do it :yes:
-
Well, I'm sure Lightspeed will if he has the time, we've already dropped an awful lot on his shoulders ;) If not, there are enough people here to help out if we put our minds to it.
Just like only a couple of people started doing Hi-Poly models at first (Nico and Galemp/VasudanAdmiral were the first, I think), and it grew from there :)
-
Originally posted by Omniscaper
Such an implementation would be useless, unless someone will take the time to create the new textures. Using a photoshop manipulated texture original will not work well. Someone will have to literaly hand trace the parts have hieght differentiation.
In reguard to normal mapping, doesn't that require a high poly version of the ships for it to be convincing? So far there are only a handfull of those. That modeller would also have to create bumpmaps from scratch to make a goodlooking highpoly model that normal mapping would draw from.
Sorry Omni, but you're slightly off the mark on this one. The way normal maps are usually created is a simple two steps:
First, a very high poly model is created. Lots of subdivision, lots of greebling. ;7
Second, this model is run through a program which takes the high poly model, and creates a low poly version and a normal map. This normal map contains much of the "missing information" from the high poly original.
The reason normal maps are so attractive is because they can make a 1500 poly model look like a 15000 poly model and not stress the video card nearly as much as more exotic techniques such as TruForm. You also get pixel perfect lighting as a bonus. The downside, however, is that you need a very high poly model to generate the maps from. I'm not sure if that's what you meant in your last paragraph, or if you meant that the card literally needs to draw the high poly version (which it doesn't).
-
Originally posted by Flipside
Just like only a couple of people started doing Hi-Poly models at first (Nico and Galemp/VasudanAdmiral were the first, I think), and it grew from there :)
Actually, Karma was first (in attemptimg ingame HTL models, not neccisarily high poly models) with his Fenris - everyone seems to forget him.
And Sticks - I didn't even know you were still around. Woot.
-
Originally posted by Sticks
Sorry Omni, but you're slightly off the mark on this one. The way normal maps are usually created is a simple two steps:
First, a very high poly model is created. Lots of subdivision, lots of greebling. ;7
Second, this model is run through a program which takes the high poly model, and creates a low poly version and a normal map. This normal map contains much of the "missing information" from the high poly original.
The reason normal maps are so attractive is because they can make a 1500 poly model look like a 15000 poly model and not stress the video card nearly as much as more exotic techniques such as TruForm. You also get pixel perfect lighting as a bonus. The downside, however, is that you need a very high poly model to generate the maps from. I'm not sure if that's what you meant in your last paragraph, or if you meant that the card literally needs to draw the high poly version (which it doesn't).
It could be that he meant that the textures for the models would need to be redone for the hi-poly version of the model. Afterall, it'd be rather pointless to match the new model to the old texture. Some of the "details" in the texture would be superfluous and new details could be drawn in.
-
Originally posted by Black Wolf
And Sticks - I didn't even know you were still around. Woot.[/COLOR]
yeah
huzza @ sticks
-
hehe, thanks guys. :)
Look for some Cool Stuff (TM) soon. Hopefully. If I can wrap my head around some of it.
-
I hope this information is helpful to someone...
Blender (http://www.blender3d.org/) is an open source 3d modeling and rendering suite that may help. Although normal maps aren't supported in Blender itself until v2.36, they can still be created using the material editor.
http://www.blender3d.org/cms/Normal_Maps.491.0.html
An unofficial pre-release version of 2.36 can be found here:
http://www.blender.org/modules.php?op=modload&name=phpBB2&file=viewtopic&t=5190
You will need to install 2.35 first, then unzip 2.36 file into wherever 2.35 was installed into. I recommend waiting the day or two until 2.36 is official. Pre-releases can be buggy, but I'm sure that's well known in another open source forum.
If this is repeated information, forgive me.
There's a few models, like the Ulysses, I plan on trying this out on myself. Hopefully someone else here felt the same way. In fact, I came here to see if normal maps were supported in FSO yet and tripped on this thread.
-
Somebody beam this man!
-
(http://dynamic4.gamespy.com/~freespace/forums/images/welcome2hlpbb.gif)
I always wanted to do that some time. ;7
-
:welcome:
misterMel_Q
:)
-
Beat you to it.:p
-
:eek2: :eek2:
http://www.blender3d.org/cms/typo3temp/75b6d42f6b.jpg
http://www.blender3d.org/cms/Gallery.55.0.html