[The E]

What would those be?

[DaBrain]

Just moving meshes around or scale them up. Just for effect.


The 3d shockwave mesh is being scaled up by the engine... somehow. I'd just like to be able to do the same.
Since I don't see PCS2 importing mesh animations any time soon (and FS2 supporting them) this seems to be the way to go.

[The E]

Nope, that's a geometry shader effect. Unless someone donates me a new PC, I'm not going to work on that.

[DaBrain]

There is one last thing I'd like to suggest though.

It's not important right now, but will come in handy later.


I'd like ot have a "shader" tab in the lab where you can edit shader values and (if possible) re-load textures. So you can work with the textures and the shaders always get an instant preview of how the effect will look in the game.

[Bobboau]

ok, first off as others have said, taking our existing texture loading systems and predefined effects is a pointless endeavor, to that extent having things like $Glow_Map: is pointless. the whole idea of the materials system is to get away from predefined effects what if the modeler wants something that doesn't have a defuse map or they want the defuse map and the shine map to be the same thing or a million other ideas that would be awkward to handle with named textures. materials should be purpose agnostic, the artist should not be constrained by the preconceived notions of whoever designed the system initially.

second putting this in the ships table is a bad idea, multiple ships are going to want to use the same effect, and a single ship will want to use more than one material. materials should be defined in their own table and referenced in the pof on the polygon level. it may sound like this would be a lot of work, but polygon already have an int for defining how they are drawn, and this int would not be needed anymore after the materials system, I am speaking of course of the texture id. but it will require the addition of a material chunk to the pof to define what textures are given to the material. in order to know how to draw a poly the game needs to know what textures to use, this is where that choice would be made, the material [MTRL] chunk, would be an array that has for each element the name of the material (defined in the material table) and an array of ints that would be the textures defined in the texture [TXTR] chunk. additionally there might be a list of floats or ints to be used as constants in the material, but that's an advanced feature that can be added on later.

now the real meat of the material system would be the material definition as defined in the material table. a material would be a way of using zero to many textures in one to many passes (each consisting of one to eight stages). to further complicate the matter graphics hardware can only handle so many lights at a time (8 last I checked) and so many textures at a time (which is why there needs to be multiple passes). each pass you would set poly wide values like alpha blending zbuffering ect and in each stage you would set stage settings like setting the first and second texture passed to the material as the input or the result of the last stage and a third texture for the second, blending options, ect. you would need a way of defining what happens on the first lighting pass vs subsequent ones

you should look over this thread (now I realize how far I've fallen ) as it starts out on how I was going to implement my system. keep in mind one of the core concepts with the way I was going to do it involved having multiple variable definitions, so the POF would have multiple vertex and index buffers defined that used only what the material needed and this would have allowed for a great deal of flexibility in the future so you could have multiple lighting normals or maybe a normal that was to be used to define geometry shader growth or something no one has thought about yet.

[The E]

ok, first off as others have said, taking our existing texture loading systems and predefined effects is a pointless endeavor, to that extent having things like $Glow_Map: is pointless. the whole idea of the materials system is to get away from predefined effects what if the modeler wants something that doesn't have a defuse map or they want the defuse map and the shine map to be the same thing or a million other ideas that would be awkward to handle with named textures. materials should be purpose agnostic, the artist should not be constrained by the preconceived notions of whoever designed the system initially.

Thank you for your input. Can you try it again, but this time, read what I said here? Those options are meant to be shortcuts for existing functionality. All in the name of making this stuff easier to use.

second putting this in the ships table is a bad idea, multiple ships are going to want to use the same effect, and a single ship will want to use more than one material.

This should work in the same way as tbl-level texture replacement. And since I'm hooking into the texture loading mechanisms, the ability to use more than one material is on the same level as using multiple textures is now.
Of course, this is where having multiple UV channels will come in.

materials should be defined in their own table and referenced in the pof on the polygon level. it may sound like this would be a lot of work, but polygon already have an int for defining how they are drawn, and this int would not be needed anymore after the materials system, I am speaking of course of the texture id.

So instead of making this system so that it can be used without having to alter the pof file format, or without altering pof data at all, you'd want to change pofs as well? I realize that there are advantages to doing it this way, but seriously? I find that trying to change too much stuff at once will only result in failure and misery.

but it will require the addition of a material chunk to the pof to define what textures are given to the material. in order to know how to draw a poly the game needs to know what textures to use, this is where that choice would be made, the material [MTRL] chunk, would be an array that has for each element the name of the material (defined in the material table) and an array of ints that would be the textures defined in the texture [TXTR] chunk. additionally there might be a list of floats or ints to be used as constants in the material, but that's an advanced feature that can be added on later.

See above. I have an intense dislike for squirreling stuff like this away in the pof, when I can just as easily define it in a text file somewhere.

now the real meat of the material system would be the material definition as defined in the material table. a material would be a way of using zero to many textures in one to many passes (each consisting of one to eight stages). to further complicate the matter graphics hardware can only handle so many lights at a time (8 last I checked) and so many textures at a time (which is why there needs to be multiple passes). each pass you would set poly wide values like alpha blending zbuffering ect and in each stage you would set stage settings like setting the first and second texture passed to the material as the input or the result of the last stage and a third texture for the second, blending options, ect. you would need a way of defining what happens on the first lighting pass vs subsequent ones

Again, feel free to break the engine in any way as you please. Me, I'm going to try and make this work within the existing framework first. Because I know what I am capable of (and, more importantly, what I am capable of testing).

[Bobboau]

So instead of making this system so that it can be used without having to alter the pof file format, or without altering pof data at all, you'd want to change pofs as well? I realize that there are advantages to doing it this way, but seriously? I find that trying to change too much stuff at once will only result in failure and misery.

fallback behaviour is easily implemented, if a pof does not have a material chunk you make one that uses a default material for every texture in the POF

Again, feel free to break the engine in any way as you please. Me, I'm going to try and make this work within the existing framework first. Because I know what I am capable of (and, more importantly, what I am capable of testing).

ok, so then you are not going to have any new functionality, you are just going to add an extra way of doing the same thing we are going now without the ability of doing anything that can't be done now? well I guess you can assign a different shader that it is SOMETHING but I don't think this really qualifies as a system so much as its simply better shader file handling.

[The E]

Way I see it, a system like this needs to be able to do just one thing: Pass arbitrary data to shaders. Which this system is set up to do.

Besides, the really interesting things can be done using some render-to-texture magic. Which I plan to do here as well.

Again, my goal here was to design a system that I can finish, maintain and extend later. Not something that does everything anyone would want to do from the get-go.

[Bobboau]

but if you make bad design choices now for the sake of simplicity you will be stuck with them for the rest of time.

a simple fact is that materials need to deal with multiple passes, lighting constraints, fall back in case the effect the artist wants won't worked ect. at the very least you need to have a pass based declaration that is purpose agnostic.

as far as passing data to shaders you would probably be better off using scripting for that, people are not going to be satisfied with constants, they are going to want engine output, weapon energy, shield strength ect.

[The E]

but if you make bad design choices now for the sake of simplicity you will be stuck with them for the rest of time.

I am, at this time, unconvinced that they are bad design choices. You had different plans, yes. Not sure if they're better plans. And again, let me stress this once more, I am aiming for stuff where I am pretty certain that I can pull it off in a reasonable amount of time.

a simple fact is that materials need to deal with multiple passes, lighting constraints, fall back in case the effect the artist wants won't worked ect. at the very least you need to have a pass based declaration that is purpose agnostic.

Not necessarily wrong, but not necessarily right either. What you see as a necessity, I see as an optional nice-to-have-eventually extra. Also remember that there aren't that many artists around in this community who can deal with this system as it is (unless people have been hiding their Shader-writing skills under a rock).

as far as passing data to shaders you would probably be better off using scripting for that, people are not going to be satisfied with constants, they are going to want engine output, weapon energy, shield strength ect.

...

And what, exactly, made you think I was unaware of this? What exactly made you think that I did not take this into consideration? Or that I rejected it?

Remember, this is just a draft. In terms of implementation, I am still at the very beginning, and it'll be some time before the first test builds.

[Bobboau]

ok, so, aside from giving some ability to specify a different shader to a ship, how will this be an improvement on what is possible. what would happen if someone wanted to make an effect that used 6 textures? this draft you have posted seems like little more than a more complicated interface to the current fixed materials, you can't do anything new, only tweak what exists.

[DaBrain]

That's what In thought at first as well, but I think you can pass as many textures into an material as you like, just like constants.

The original texture on the model doesn't even matter. That's just the name of the material.

[The E]

The draft I posted allows you to define an arbitrary* number of arguments to be passed to a shader. What the shader(s) then do with that data is none of my concern.
Now, for the moment, it's limited to a single-pass rendering, but there's a lot you can do in a single pass.




*For values of arbitrary lower than 16

[Bobboau]

so a texture can be passed as an argument?

how do you handle an object being lit by 37 lights?

how do you handle alpha blending?

[The E]

so a texture can be passed as an argument?

Yes.

how do you handle an object being lit by 37 lights?

I don't. Not until there's multi-pass rendering. And as I said, that's something to try later.

how do you handle alpha blending?

Cross that bridge when I come to it.

[pecenipicek]

as a side question, what are the concrete shader system limits? (complexity, shader size, shader number, etc,etc)

[Nuke]

Way I see it, a system like this needs to be able to do just one thing: Pass arbitrary data to shaders. Which this system is set up to do.

Besides, the really interesting things can be done using some render-to-texture magic. Which I plan to do here as well.

Again, my goal here was to design a system that I can finish, maintain and extend later. Not something that does everything anyone would want to do from the get-go.

i like the sound of "render-to-texture magic". i kinda hope this makes things much much faster as far as rtt goes. right now its somewhat crippling when you use it through scripting. a couple of low res sensor displays can really set you back several fps.

[The E]

as a side question, what are the concrete shader system limits? (complexity, shader size, shader number, etc,etc)

A lot of those are depending on the GPU, or rather the supported Shader Model.