Shader model beefs



Users browsing this forum: No registered users and 2 guests

Next topic
Previous topic
Post new topic Reply to topic  NeoAxis Forum Index » General » General Discussion
Search for:
Author Message
New Professional License
New Professional License
User avatar

Joined: Sat Dec 18, 2010
Posts: 460
Country: United States (us)
PostPosted: Tue Dec 20, 2011 4:54 am Post subject: Shader model beefs
Bottom of Page Back to top
I noticed that 1.1 Final only compiled 3.0 shaders. Why wasn't 2.0 compiled? Are you taking the stance not to support it any more? Is OpenGL shader model not being supported any more either? Can't get that to Compile either?

Please add documentation on why some highmaterials work on 2.0 and some don't for some other reason.

Compiling and waiting for errors is a waste of time and confusing, and needs to be streamlined a bit more. We want to support 2.0 and 3.0. How can we do that? I am willing to suggest the compiler and editors support at least 2 directories. One for 2.0 materials and 3.0 materials, and when you are compiling for one or the other it ignores the other so we can support as many people as possible. The editors should further more not see duplicate materials for shader compatibilty issues. For example, not crash the RE on duplicate naming for materials with the same name to support compatibilty . If the same named material is named for the shader model 2 and shader model 3, they shouldn't cause a crash, and be used accordingly.

Thanks for listening...

Incin

_________________
Ms3d Exporter
 
 Profile  
User avatar

Joined: Fri Dec 17, 2010
Posts: 347
Location: HK
Country: Hong Kong (hk)
PostPosted: Tue Dec 20, 2011 1:44 pm 
Bottom of Page Back to top
I've been doing some tests with the cache now it works for me with 1.1. I'd like to know why and how some things seem to be shader 2.0 compatible/optional, like the "halfLambert" lighting. The Village Demo in 1.1 runs with shader 2.0 yet showcases these new things, so they seem to me to be hardcoded to simply turn off when the user has shader 2.0 hardware. The cache can't be compiled for shader 2.0 with these things in the material files, yet I suppose (and it seems to work this way) they can just be deleted before compile, placed back afterwards and still work? This is really confusing.

Knowing how the Village Demo can still run with shader 2.0 while these 3.0 features are being referenced in the material files it uses, whether it uses cache or not, I think would be very useful to know.

I have some ideas but I'll make another post.
_______________________
Quote:
Is OpenGL shader model not being supported any more either? Can't get that to Compile either?
We have a problem with this. NA 1.1 comes with "Caches\ShaderCache\OpenGL_ShaderModel3_General.shaderCache", so maybe because we're both ATI graphics, we have this problem. When we try to compile OpenGL with shader 3.0, it spits out a "not supported" error at us.
_______________________

I just compiled both DirectX and OpenGL shaders for 2.0 with the vanilla 1.1 release. I had to delete a few files, 2 "Tree_Leafs", 1 "Girl" and all the "Farm*Transparent" materials, about 12 highMaterial files that the cache compiler didn't like. It compiled with those missing and the loading times were much better when using shader 2.0 setting, so that proves the shader cache can be partially compiled and still make a huge difference to loading times.


Last edited by LDAsh on Tue Dec 20, 2011 8:16 pm, edited 2 times in total.


 
 Profile  
User avatar

Joined: Fri Dec 17, 2010
Posts: 347
Location: HK
Country: Hong Kong (hk)
PostPosted: Tue Dec 20, 2011 7:23 pm 
Bottom of Page Back to top
I've been thinking, maybe a better way would be to cull stages/instructions of materials when used for shader 2.0, and actually manage that in the files? Different folders and duplicate names sounds like asking for trouble, unless they could be identified in this way, anyway. I get the impression this is already happening for the fancy stuff, the game will still work with shader 3.0 (64+ instructions) in the highMaterial files with shader 2.0 settings, so everything still works but not able to compile the cache (still allowing a partial compile) because it seems the engine already accounts for its (non-)compatibility and simply doesn't try to use it. That's stuff like "halfLambert" and other new stuff showcased in the Village Demo.

When it comes to other stuff like "diffuse*Map" with scaling, which layers of really eats up instructions, cubemap reflections, specularity, etc, understandably there's no way to know how to turn it off for shader 2.0 compatibility, because it's all so standard, just used in combinations that are too much work for shader 2.0. On top of that, there's no way to automatically know which features will change the visuals of the material in unwanted ways. Maybe the cubemap reflection is subtle and can be disregarded, or maybe it's prominent and vital to the appearance of the surface, far more than detail-mapping at "diffuse2Map". There's no way for code to automatically know this.

So I'd like to suggest a way to manage this within the highMaterial files themselves, so that they know what standard things to cull for shader 2.0 compatibility. It could very well be just 1 option and save a lot of instructions, so for example:-
Code: Select all   Expand view
highLevelMaterial "cc1/apartmentdoor"
{
   template = ShaderBaseMaterial
   shader2cull = reflection        <--- new code
   receiveSimpleShadows = True
   reflectionColor = 1 1 1
   reflectionSpecificCubemap = "Types\\Base\\SkyBox\\env_water1.jpg"
   specularColor = 1 1 1
   specularPower = 1
   specularShininess = 512
...
becomes like the equivalent of (for shader 2.0):-
Code: Select all   Expand view
highLevelMaterial "cc1/apartmentdoor"
{
   template = ShaderBaseMaterial
   shader2cull = reflection
   receiveSimpleShadows = True
//   reflectionColor = 1 1 1
//   reflectionPower = 1
//   reflectionSpecificCubemap = "Types\\Base\\SkyBox\\env_water1.jpg"
   specularColor = 1 1 1
   specularPower = 1
   specularShininess = 512
...

shader2cull = reflection / specular / emission / diffuse2map / diffuse3map / diffuse4map...
Only these, mainly, because it's surprising what eats up instructions and what does not.

That's the simple version of the idea, I guess. Perhaps Incin's folder idea is better because when we get right into complicated effects, it's the only true way to go to make things as visually correct as possible, but I fear it may increase loading times too much, which is important to avoid. Having more control inside the actual one set of highMaterial files themselves shouldn't harm loading times and like I said, 99% of the time it really could be that simple.

 
 Profile  
New Professional License
New Professional License
User avatar

Joined: Sat Dec 18, 2010
Posts: 460
Country: United States (us)
PostPosted: Fri Dec 23, 2011 5:03 am 
Bottom of Page Back to top
Making the materials work seems that any transform additions fails for 2.0 past the first material. Error messages are the shader doesnt support negative Pow() or more then 64 instructions. Deleting the transforms or scales make it work for 2.0 on Diffusemaps and anything below the primary diffuse shader. Hopeflly you can make changes to coincide with this.

_________________
Ms3d Exporter
 
 Profile  
Display posts from previous:  Sort by  
Post new topic Reply to topic  NeoAxis Forum Index » General » General Discussion

Jump to:  

Next topic
Previous topic
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

cron

All times are UTC




Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group