[foolfromhell]

Im gonna guess...
3.2 GHz P4 w/ HT.
1.75GB RAM.
Nvidia 6600 w/ 256mb VRAM on AGP8x.
200GB HDD.
Would this work? with all the advanced effects with at least 30FPS? Im still trying to get FSOpen with all effects to work. Will it?-

[Gregster2k]

We've got to wait for all of the data to catch up too.  The MediaVPs are still lagging behind at the moment.  With the shader support, we'll actually need shader effects, so that will be something for people to come up with.  And I've got partially working bumpmap code with these test images I've been sent, so that will be something else that the map makers will have to deal with when that hits CVS.  I'll probably add the bumpmap support about the same time as the shader support hits CVS so those things will hit everyone at once.  The problem is, of course, that those features are useless without the data to go with them.  :

I'm no coder (at all, lmao), but I might have some fun tweaking shaders a bit once I see the shader system you guys are doing. I'm a tinkerer...maybe I'll figure some junk out or something. =P

Are there any programs out there that do bloom for any Direct3D application? I have a bunch of (non SCP) programs that are Direct3D only that I want to put bloom on... >_>

[DaBrain]

cant we just use the glowmaps for that? we already have too many maps to work with as it is.

The more maps you got, the more possibilities you are open for you.
The number of used maps is rather high in FS2. Well, at I can do something about this. At least of the standard FS2 and mods, based on the FS2 content.
It will be part of the MediaVP. Actually... I'm almost done with it too. 
FS2 never made use of mipmaps and rather used downsized versions of the original maps for lower lods. So almost all lod textures for the lods aren't needed anymore, now that we got mipmapping.

We will need artists to create greyscale textures that will represent amount of the glow. Right now everything is maxed out and it can look very bad in some cases.

Well, it's no problem for me to convert all glow maps into greyscale maps. It would actually take a few minutes only.
I'm a bit worried about animated textures. How are we going to handle them?

[wolf]

Well, it's no problem for me to convert all glow maps into greyscale maps. It would actually take a few minutes only.

Such conversion would be pointless, as it can be done within the shaders with negligible performance hit. The point is, however, that the current glow maps may not be approptiate as the bloom glow maps.

I'm a bit worried about animated textures. How are we going to handle them?

Are there any bloom related issues with them?

[DaBrain]

Well, how do I have to set up a map for the bloom effect? An example would be great.


And about animated effect:
If there is an animated texture and lets say it's an EFF using DDS frames, how would I have to set up the bloom file for it?

AnimatedMap_0000.dds, AnimatedMap_00001.DDS

Like... errmm:

AnimatedMap-bloom_0000.dds, AnimatedMap-bloom_0001.dds


Is DDS fine for this? It can be greyscale. And would we need mip maps for this? If it works a bit like I think, mip maps might speed it up...

[Nuke]

i really hope that procedural materials would replace animated glowmaps. considering th way theyre being used now, that fade effect could be scripted quite easily.

[DaBrain]

A lot of animations could be replaced, but some are just too complex be replaced. We still need support for them.

[Nuke]

keep support for them, yes, but for effitiency, swap em out for procedurals if those look better, or provide a significant performance increase, and swap em especially both of those turn out to be true.

[neoterran]

I dont' suppose we could see a uh... test build... before it gets into cvs could we ? you know, for the hardcore...

[Gregster2k]

:3?!

[taylor]

I dont' suppose we could see a uh... test build... before it gets into cvs could we ? you know, for the hardcore...

There will be a test build before the code hits CVS.  BUT, 3.6.9 comes first, so I'm not putting much work into this until after we finally get 3.6.9 out the door.  The test build will be for the shader support and the normal mapping support, so everyone has to wait until both features are pretty much working before a build comes out to test them.

[DaBrain]

I love those big improvements. Getting two great visual improvements (or the possibilities for them) at once will be awesome.

3.6.9 has a higher priority of course, but I fear most people will rather stick to your test build.


Anyway, the final 3.6.9 build will be pretty important for the BtRL demo release. As it would delay the release date too much, while the possibilty of problems is rather high, the demo probably won't feature normal mapping or any pixel shader effect/materials.



I will continue to work on normal maps, unless you tell me that my preview maps aren't useable and have to be created in a different way.

[taylor]

3.6.9 has a higher priority of course, but I fear most people will rather stick to your test build.

I think that I've only mentioned this in internal, but all of my upcoming feature work will use 3.6.9 as a base.  It's one of those "easier to build a house on a mountain than a sand dune" type things.

The test build will basically be 3.6.9, but with the bump mapping and shader support.  So in that respect it won't really matter if people use the test build over 3.6.9 or not.  If there is a bug somewhere then it will be related to either shaders or normal maps, and both of those things will only be enabled via cmdline options.  That will make it a lot easier to track down and/or identify bugs since I won't have to worry about whether that particular bug is something in unstable CVS or my new code.  If what ever goes wrong happens in my test build and not 3.6.9 then I'll know for sure that it's something with my code changes.

I will continue to work on normal maps, unless you tell me that my preview maps aren't useable and have to be created in a different way.

You're maps appear to work fine.  I was able to get a generally bumpy Perseus and that looked halfway decent (it will be a lot better once the lighting code for it catches up).  The maps I got from Vasudan Admiral didn't work out so well though, they seem inverted.  Whether that's just the maps or partially the code I don't know.

The code mainly just needs a lot more work to blend and light it all properly.  Plus some speed adjustments will be needed, not to mention a change or two to how the extra lighting passes get handled.

Unless you just have a good bit of time to work on the normal maps you may just want to get a decent sample to test with with for the test build and then wait on getting maps for everything.  We'll need maps for some fighters, bombers, cruisers, capital ships, and some mods (SoL and BtRL mainly) in order to get a good test for speed and memory usage.  Doing everything can wait, just in case some changes are needed. 

[neoterran]

Once the shader support (I assume we'll be able to do otherthing than Bloom using this, simply by writing additional vertex programs right? Is there some kind of loading support to come with this or will these additional vertex programs need to be put into the CVS by a coder ?) stablizes and we have normal maps for everything... wont' that truly be deserving to be version bumped to 3.7.0 ?

[DaBrain]

@taylor
Sounds reasonable.

I'm doing the normal map in a cheap way. This way only the surface will get more details. I'm just creating a hieght map and convert it. Normal mapping would be way more effective in connection with a high-poly model. So a low-poly model looks almost like a high-poly one.

So this feature has even more potential than I can get out of it right now...

I've just read some very good articles about normal mapping. Well, I may start working on normal maps properly soon, but I'm not as good with model, as I am with textures... yet. 


This should get some people motivated to help with the release candidate testing:
If you help to squeeze ou the last bugs of the test builds, you'll get to see the new features sooner.

In a few days I'll be able to help with the testing too.

[taylor]

Once the shader support (I assume we'll be able to do otherthing than Bloom using this, simply by writing additional vertex programs right? Is there some kind of loading support to come with this or will these additional vertex programs need to be put into the CVS by a coder ?) stablizes and we have normal maps for everything... wont' that truly be deserving to be version bumped to 3.7.0 ?

Shaders will work out of special tbls, or tbms rather, so it will support future upgrades and such.  How this will work exactly is still up in the air, and one of the major hold-ups, since it would be good to support full scene shaders without code changes.  Doing that isn't a problem, but actually deciding on the best/easiest way to do it is. 

At this point, there will be no default shaders included.  They will all be MediaVP-type data only so you will require the actually tbms in order to use any shader.  I figure this will work out better for everyone since it will give mods far more control over how things work rather than just some default effects getting applied that they can't control.


We won't go to 3.7 until the new pilot file code is in.  3.7 is going to be big.  Seriously BIG.  There a quite a few upgrades to various parts of the code that have been waiting for the new pilot file code so there is a seriously large number of changes coming, and that's just from me.  Then there is the new sound code, the all new OpenGL init code (finally with real AA support in OGL), the new ANI replacement, etc.  I'm still sitting on a few changes that I originally started the first of last year.  Between my 3 different code trees of new features I've got over 100,000+ lines of code changes just eating a hole in my hard drive. 

That's why I'm focusing on getting 3.6.9 as good as possible, I'm going to stop fixing bugs and start working almost 100% on new features.  I've fixed like 600+ bugs over the past 2 ½ years and it's time to just work on my own new features for a change.

[neoterran]

Whoa, okay i guess we'll be looking at 3.6.10 type chicanery then.

I hope you're putting this work on your resume Taylor, as it's really of work from you to upgrade to upgrade a 7 year old game engine

Thanks to you and all the others on the forum who improve it too (you know who you are)

[Mehrpack]

Shaders will work out of special tbls, or tbms rather, so it will support future upgrades and such.  How this will work exactly is still up in the air, and one of the major hold-ups, since it would be good to support full scene shaders without code changes.  Doing that isn't a problem, but actually deciding on the best/easiest way to do it is. 

At this point, there will be no default shaders included.  They will all be MediaVP-type data only so you will require the actually tbms in order to use any shader.  I figure this will work out better for everyone since it will give mods far more control over how things work rather than just some default effects getting applied that they can't control.


We won't go to 3.7 until the new pilot file code is in.  3.7 is going to be big.  Seriously BIG.  There a quite a few upgrades to various parts of the code that have been waiting for the new pilot file code so there is a seriously large number of changes coming, and that's just from me.  Then there is the new sound code, the all new OpenGL init code (finally with real AA support in OGL), the new ANI replacement, etc.  I'm still sitting on a few changes that I originally started the first of last year.  Between my 3 different code trees of new features I've got over 100,000+ lines of code changes just eating a hole in my hard drive. 

That's why I'm focusing on getting 3.6.9 as good as possible, I'm going to stop fixing bugs and start working almost 100% on new features.  I've fixed like 600+ bugs over the past 2 ½ years and it's time to just work on my own new features for a change.

hi,
woow, sound really great and interesting.

Mehrpack

[Chris B. Yond]

What kind of shader support is this exactly? Is it going to be limited to pixel shader v2.0 and above? There are neat things you could do with v1.3 nevertheless (I'm asking this because of my old "v1.3"-card and a nasty lack of money ).

[DaBrain]

I think we're not limited to a special shader version.

Of course we shouldn't blindly use 3.0 shaders, but afair 1.3 is pretty limited. Especially be the instructions that can be worked on at the same time.
I think I just got a good idea.

I bet it's no problem to find out the the supported shader versions of  card. How about different versions of the shader entries in the tables. Like fallback modes for people with older cards. I know this means more work for the modders, but most modders would neither want to use worse graphics than they could actually have, nor to make low-end users unable to run their mod.

1.1, 2.0, 3.0?

If there is no way to recreate an effect with a lower version, the modder could still add a dummy shader, that does nothing.