1.1 request: Can we have UV multipliers for all Material channels?
by James Brad Barnette · in Torque 3D Professional · 12/06/2009 (8:25 pm) · 16 replies
Would it be possible to get UV multipliers for other material channels than just detail. it would be nice to have spec pas and normal maps that follow the UV multiplier of the detail map and not the 1:1 of the diffuse channel.
About the author
#2
12/07/2009 (3:49 pm)
yeah but would be good to have the feature for other channels especially spec 
#3
12/07/2009 (3:53 pm)
This certainly would be a valuable addition to have to Torque as there are times when you would want to use a symmetrical diffuse bitmap and have unique uvw coordinates for your normal. Its not something that is needed all the time but would be useful. 
#4
So lets say each map had an arbitraty x and y scale... thats one for texture map, detail map, overlay map, normal map, detail normal map, specular map, light map, and tone map. So thats 8 in total. In essence this is 8 instructions per-pixel to multiply UVs in addition to everything else your doing.
Its also 8 new shader constants sent from the CPU to the GPU for each material drawcall batch rendered to the scene.
My point is these things add up and when you can build your UVs right to begin with and don't do it in the shader.
I kinda have some ideas as to where Torque shaders are going in the next 6 to 12 months and i'd rather focus on that then hack in this one "it would be nice" feature.
And you'll all be very happy. ;)
12/08/2009 (3:30 am)
My concern is only abuse and wasted pixel shader instructions, input registers, and/or state changes.So lets say each map had an arbitraty x and y scale... thats one for texture map, detail map, overlay map, normal map, detail normal map, specular map, light map, and tone map. So thats 8 in total. In essence this is 8 instructions per-pixel to multiply UVs in addition to everything else your doing.
Its also 8 new shader constants sent from the CPU to the GPU for each material drawcall batch rendered to the scene.
My point is these things add up and when you can build your UVs right to begin with and don't do it in the shader.
I kinda have some ideas as to where Torque shaders are going in the next 6 to 12 months and i'd rather focus on that then hack in this one "it would be nice" feature.
And you'll all be very happy. ;)
#5
personally I wish the whole thing would get thrown out in favor of a more nodal approach like in unreal. But that also would take 12+months.
perhaps this then you have a global multiplier for the material and then each channel has a check box on wether it uses it or not. so for instance you could say set it to 6 and then check say normal, spec, detail, illumination. and they would all tile.
I would be wrong but that would create no more UV sets than what we have now no?
12/08/2009 (11:21 am)
There is always going to be something better down the road.personally I wish the whole thing would get thrown out in favor of a more nodal approach like in unreal. But that also would take 12+months.
perhaps this then you have a global multiplier for the material and then each channel has a check box on wether it uses it or not. so for instance you could say set it to 6 and then check say normal, spec, detail, illumination. and they would all tile.
I would be wrong but that would create no more UV sets than what we have now no?
#6
I like Unreals system too, however we have to keep in mind that Unreal builds all their shaders through this editor as well through its own native code that then eventually becomes whatever shader language its needed when its used. So with that said having a nodel system for their equivilent of the "material" system makes a lot more sense than say Torque doing the same thing. Though with that said, I use a text editor more than the Material Editor system, simply because the Material Editor really isn't that well thought out for power/production usage (great for simple stuff though), so theres definately room for improvement IMHO (and I know Tom's got something interesting up his sleeve).
12/08/2009 (6:01 pm)
I think Tom's concern is that in the untrained hands this feature could potentially be a detriment to the software since it would be easy for anyone to accidentally flip the switch. Personally I think this is more of a "power user" option that would be nice to have still for those circumstances where its needed, aka: the occasional character model.I like Unreals system too, however we have to keep in mind that Unreal builds all their shaders through this editor as well through its own native code that then eventually becomes whatever shader language its needed when its used. So with that said having a nodel system for their equivilent of the "material" system makes a lot more sense than say Torque doing the same thing. Though with that said, I use a text editor more than the Material Editor system, simply because the Material Editor really isn't that well thought out for power/production usage (great for simple stuff though), so theres definately room for improvement IMHO (and I know Tom's got something interesting up his sleeve).
#7
12/09/2009 (12:07 am)
At the least, it will be interesting to see where all of this goes.
#8
Dig the original news posting.
Its actually very powerful and its a shame that its complexity in implementation kept the Torque community from enhancing it over the last 6 years.
We did alot in Torque 3D 1.0 to extend the current system, but its time for a massive rewrite.
You can bet on a few things:
1. The most commonly used interface for most artists won't be all that different in concept from the current material editor... fill out some fields with textures and various constants.
2. Technical artists and/or shader programmers will be able to use a new editor which will allow you to assemble new shaders from predefined features or new features you write. These new shaders will then be available from the simple UI for use by others.
3. You won't have to write any C++ or TorqueScript to extend the system. Only HLSL and some GLSL if you want to support those platforms that require it.
This is all i can say at the moment as its all i've figured out. :)
12/09/2009 (7:11 am)
You have to remember TGEA had its ShaderGen system when it shipped in 2004 more than 2 years before the first Unreal3 game shipped... over 3 years before if you count development time. Dig the original news posting.
Its actually very powerful and its a shame that its complexity in implementation kept the Torque community from enhancing it over the last 6 years.
We did alot in Torque 3D 1.0 to extend the current system, but its time for a massive rewrite.
You can bet on a few things:
1. The most commonly used interface for most artists won't be all that different in concept from the current material editor... fill out some fields with textures and various constants.
2. Technical artists and/or shader programmers will be able to use a new editor which will allow you to assemble new shaders from predefined features or new features you write. These new shaders will then be available from the simple UI for use by others.
3. You won't have to write any C++ or TorqueScript to extend the system. Only HLSL and some GLSL if you want to support those platforms that require it.
This is all i can say at the moment as its all i've figured out. :)
#9
detail maps aren't exactly what i'd call a good solution. a far more powerful one exists in texture blending. a limited version of only 3 textures can give startlingly good results. the only real problem is it takes a good artist, good textures and a good knowledge of the 3dapp your using. it's not the brutal approach detailmaps are.
http://3.bp.blogspot.com/_atChMaTmVQ4/Sj2Iw1BwZJI/AAAAAAAAABA/Ey-TqKO_EWA/s1600-h/crysissux.jpg
is 4x 512x512 textures plus normalmaps. the same amount of memory as a 1024x1024 plus normalmap yet that level of detail is impossible from one texture and is too dynamic for detailmaps to ever match.
keep in mind the more you do to the standard shader the slower every scene gets. at some point you start needing to draw a line and tell people to implement at their own risk.
12/09/2009 (8:14 am)
personally i think custom shaders are far more useful than one over bloated uber shader. and i'm kinda hoping this rewrite involves a shift to SM5.detail maps aren't exactly what i'd call a good solution. a far more powerful one exists in texture blending. a limited version of only 3 textures can give startlingly good results. the only real problem is it takes a good artist, good textures and a good knowledge of the 3dapp your using. it's not the brutal approach detailmaps are.
http://3.bp.blogspot.com/_atChMaTmVQ4/Sj2Iw1BwZJI/AAAAAAAAABA/Ey-TqKO_EWA/s1600-h/crysissux.jpg
is 4x 512x512 textures plus normalmaps. the same amount of memory as a 1024x1024 plus normalmap yet that level of detail is impossible from one texture and is too dynamic for detailmaps to ever match.
keep in mind the more you do to the standard shader the slower every scene gets. at some point you start needing to draw a line and tell people to implement at their own risk.
#10
12/09/2009 (11:14 am)
yeah I'm not a big fan of the way the detail maps work at all. Mainly the math used it just doesn't seem like the best choice perhaps a choice of blending modes could improve this in the short term. 
#11
12/09/2009 (12:37 pm)
@Tom: Awesome!!!
#12
The only people i know of not using detail texturing is Id and they don't blend anything at runtime at all... its all one giant baked unique texture.
I think you'll see more and more complex detail texturing techniques... including different blend modes... in the next 2-3 years.
12/09/2009 (11:25 pm)
Quote:personally i think custom shaders are far more useful than one over bloated uber shaderTo be clear... Torque has never used an 'uber shader' method. Each material builds a shader procedurally which includes only the features it needs. I don't forsee that chaning in the future either.
Quote:and i'm kinda hoping this rewrite involves a shift to SM5.Well... duh. :)
Quote:detail maps aren't exactly what i'd call a good solutionDepends on what you mean by good... but the entire game industry seems to have the opposite view of them. If you pick out a game with great looking graphics that is shipping today... they use some form of detail texturing.
The only people i know of not using detail texturing is Id and they don't blend anything at runtime at all... its all one giant baked unique texture.
I think you'll see more and more complex detail texturing techniques... including different blend modes... in the next 2-3 years.
#13
Speaking of which.. I wanted to spend some time changing the blending method from the current one to something that is based on normal maps. Now that we have detail normals.. :) You had a plan to do this sometime when you first showed the terrain system off. Is this still planned?
12/10/2009 (6:41 am)
Quote:
I think you'll see more and more complex detail texturing techniques... including different blend modes... in the next 2-3 years.
Speaking of which.. I wanted to spend some time changing the blending method from the current one to something that is based on normal maps. Now that we have detail normals.. :) You had a plan to do this sometime when you first showed the terrain system off. Is this still planned?
#14
12/10/2009 (8:34 pm)
@Konrad - By normal map based blending you mean like based on the slope of the surface?
#15
Edit: To be more exact, the current linear blending should still be applied except with a weigh set by the lower texture's normals. The steeper a normal is at any pixel, the less the higher texture would appear on it.
12/10/2009 (8:42 pm)
@Tom: Yes, exactly that.Edit: To be more exact, the current linear blending should still be applied except with a weigh set by the lower texture's normals. The steeper a normal is at any pixel, the less the higher texture would appear on it.
#16
if they still work, that's probably a better long term result. the automatic stuff needs to be an editor function that stores a final result. angle and altitude is preferred. ie anything below water level would obviously exclude grass. and above a certain height should be getting snowy.
@Tom: lots of people might use detail maps but i don't have to like the end results. stalker is by far the worst example. everything looks like it's hosed down in porridge. you still get obvious tiling. texture blending gives you the chance to blend between 3-4 similar textures to blend out obvious tiling. all using a very small amount of memory if you don't go overboard.
i'm not asking you to implement this, but if we can play around in hlsl more easily we can implement whatever we want, we can now i would guess but i have enough issues getting softimage to co-operate with my videocard(s) not enough to start learning hlsl.
12/10/2009 (10:59 pm)
there is/was some angle based painting masks in b5. i've been juggling graphics driver issues since 1.0 released and haven't played with much since. if they still work, that's probably a better long term result. the automatic stuff needs to be an editor function that stores a final result. angle and altitude is preferred. ie anything below water level would obviously exclude grass. and above a certain height should be getting snowy.
@Tom: lots of people might use detail maps but i don't have to like the end results. stalker is by far the worst example. everything looks like it's hosed down in porridge. you still get obvious tiling. texture blending gives you the chance to blend between 3-4 similar textures to blend out obvious tiling. all using a very small amount of memory if you don't go overboard.
i'm not asking you to implement this, but if we can play around in hlsl more easily we can implement whatever we want, we can now i would guess but i have enough issues getting softimage to co-operate with my videocard(s) not enough to start learning hlsl.
Associate Tom Spilman
Sickhead Games