Exporting used UV Channel from a Script Material

Hello!
I’m messing around a little with xna and such. Up till now I’ve used a .fx file directly, using the directX material.
It worked fine for simpler materials, and I could assign and preview the shader while modelling. Quite handy. There I could select what uv channel the texture should use. So, quite practical, although the gui was limited.

So, I looked into scripted materials which extend the DirectX material. I had a look at the tutorial in the wiki here, and it works fine.
However, I haven’t figured out how to transfer the used UV Channel into the shader material.
Usually I setup a texture for the .fx file like this:
texture DiffuseMap : DiffuseMap
<
string UIName = “Diffuse:”;
int Texcoord = 0;
int MapChannel = 1;
>;
So, if I load the .fx file directly, I get a spinner where I can choose the UV’s. But, how do I do this for the scripted material?

Kjetil

[QUOTE=Kjetil;3738]Hello!
I’m messing around a little with xna and such. Up till now I’ve used a .fx file directly, using the directX material.
It worked fine for simpler materials, and I could assign and preview the shader while modelling. Quite handy. There I could select what uv channel the texture should use. So, quite practical, although the gui was limited.

So, I looked into scripted materials which extend the DirectX material. I had a look at the tutorial in the wiki here, and it works fine.
However, I haven’t figured out how to transfer the used UV Channel into the shader material.
Usually I setup a texture for the .fx file like this:
texture DiffuseMap : DiffuseMap
<
string UIName = “Diffuse:”;
int Texcoord = 0;
int MapChannel = 1;
>;
So, if I load the .fx file directly, I get a spinner where I can choose the UV’s. But, how do I do this for the scripted material?

Kjetil[/QUOTE]

We used scripted materials at one point, but then I made an effort to get rid of them and since then we had far less problems.

I can’t remember all the problems as its long ago, for one you could not drag and drop etc on the slots to load bitmaps. Also there may of been problems when updating the shaders that have new features - adding new constants?

I think they would of worked if our shaders didnt change, but they did frequently.

You also had to maintain the scripted materials, the script IDs and fx files alll together.

Sorry I cant offer only vague reasons, but I do remember it being a big weight lifted when we switched to not using scripted materials!

They were’nt worth it for the material looking more artist friendly.

I just remembered…

with the standard dx9 materials if you keep use the same sampler names and constants you can switch shaders which contain the same naming, just by loading the new shader from the top of the material. I think this is impossible with scripted materials, you would have to write a special scripts to convert between different shaders if you used scripted materials. Or you will loose your textures from the slots. This makes it easy for the artists to switch between shaders.

I think if shaders are missing it will default to the default.fx, so its worth putting a check in when you load a file in max it does a check for any materials in the scene that use default.fx and pop up a warning so the user doesnt save this file with lost shader info.

I used scripted DX materials in the last studio I worked for and it required a ton of overhead to keep stable. The benefit was that the artists authored their content using the exact shaders that were in the game engine. Getting the correct UV’s to pass through from Max to the shader was a pain. We ended up doing it via a preprocessor constant since we used a Super Shader. I would never do this again. Spend your time on fast iteration from DCC to game engine instead. It will reward you 1000% more than focusing your effort on this. The only reason I ended up doing it this way is because we had a completely backward, non-tools focused studio that refused to help out the artists in any way, shape or form for years (it finally got better a couple of years before the whole team got axed). If you are dead set on doing it this way, here’s a sample of how I ended up doing it:

In the scripted material extension parameters:

parameters main rollout:params
(

iDetailUVChannel type:#integer default:1
iBumpUVChannel type:#integer default:1
iSpecMapUVChannel type:#integer default:1


)

And the script that generated the temporary .fx file that set the preprocessor constants and then included the main .fx file:

if thisMat.bHasDetailMap then
(
format "%
" “#define SHD_DETAIL” to:thisFXFile
if thisMat.iDetailUVChannel != 1 then format "%
" “#define SHD_DETAIL_MULTI_UV” to:thisFXFile
)

format "

%" “//Include the main .fx file from the engine
#include <…\General.fx>” to:thisFXFile

In the material declarations of the .fx file:

#if defined(3DSMAX)
texture BaseTexture < string UIName = “Diffuse Texture”; int Texcoord = 0; int MapChannel = 1; >;
texture DetailTexture < string UIName = “Detail Texture”; int Texcoord = 1; int MapChannel = 2; >;
texture BumpTexture < string UIName = “Normal Texture”; int Texcoord = 1; int MapChannel = 2; >;
texture SpecularTexture < string UIName = “Specular Texture”; int Texcoord = 1; int MapChannel = 2; >;
#else

In the vertex shader struct:
struct VS_INPUT
{

#if defined(PS_NEEDS_MULTI_UV)
float2 vTex2 : TEXCOORD1;
#endif

};

So the 2nd UV set would be passed out of the vertex shader via Texcoord1. Then the logic takes over in the main body of the shader:

#ifdef SHD_DETAIL_MULTI_UV
o.ToPix.TexDetail.xy = vTex2 * DetailScale;
#else
o.ToPix.TexDetail.xy = vTex * DetailScale;
#endif

We used a super shader and we ended up creating a single scripted DirectX material extension that had every possible element in it. If you do decide to use a scripted DX Material extension, here are the things you will have to manage every time you open a file:

  1. Find the path to a valid .fx file or default.fx will be used instead. (And of course Max stores hard-coded paths here.)
  2. Find the path to all of your run-time .dds texture files or the shader will look incorrect. (And of course Max stores hard-coded paths here as well.)
  3. A function that makes a correlation between the scripted Material data and the UI slots created from the .fx file in the DirectXMaterial

The nice thing about the scripted DirectX Material extension is that it actually saves your data. If you just use the DirectX Material directly, you will lose all of your data the first time you open that file and it can’t find the path to the .fx file. So an artist opening a file on a different machine will ruin the file’s shaders.

My recommendation: Don’t do this! Store the data in an extensible, schematized format like XML and create a simple authoring tool. Make a material name in 3ds Max / shader data correlation. Then just arbitrarily update the materials with temporary Direct X Materials if you want to visualize them in Max (be sure not to change the name of the material in the Max file ever). You could write a function to update the materials and then run that function whenever something changes or loads. Don’t store custom game data in Max whenever you can avoid it. And doing that would take about the same amount of work as writing and managing the scripted DX Material (well over 3500 lines of script in our case).

Good luck!

本公司备有大中小型机械,[b]北京怀柔区管道疏通[/b]承接北京怀柔区管道疏通、下水道疏通、疏通管道、高压清洗、高压水射流清洗、[b]北京怀柔区管道疏通[/b]疏通 下水道等各种疑难管道疏通、疏通清洗、高压清洗工程、化学清洗工程、清洗管道、管道维修、高压清洗管道,彻底清除掉管道内积存多年的尿碱污垢等。 高压水射流管道清洗,各种疑难下水管道疏通清洗、各类管道的清洗,[b]北京怀柔区管道疏通[/b]化学清洗工业设备,[b]北京怀柔区管道疏通[/b]化学清洗各类管道、修理下水道、专业疏通下水道的堵塞、疏通管道的堵塞、马桶维修,修理下水道[b]北京怀柔区管道疏通[/b]、清洗管道、疏通主管道、疏通马桶 、疏通蹲坑、疏通地漏 、疏通厨房菜池、疏通厕所、疏通浴缸、疏通小便池。

Sounds like you had similar issues torgo3000,

We havent had any problems with Standard DX materials and Artist trashing files, there are plenty of warnings if someone loads a file with missing .fx shaders and everything is under source control. Everyone has the same exact paths on their machines to textures and .fx files. Its possible to mess things up, but our team is generally good and not doing that (he says with all fingers crossed)

Hey guys. thanks for the feedback and information.
It’s interesting to hear others experiences and opinions.

I did get this working finally, by supplying integer values from 3dsmax choosing the right uv channel. Then I used this value to pick the right uv channel from an array containing the number of uv channels available. I got this tip from one of the tools guys at work. Much more elegant solution than what I came up with.

I do work with games, but as a technical artists. So my main occupation is not programming, but it’s interesting to be able to do some programming, and understand a bit what’s going on under the hood.

So, this tool is more for one of my own smaller xna projects. :slight_smile: I still like to have things tidy and woorking smoothly :slight_smile:

Anyway, using a scriptable material extention of a directx material seems to work fine, and mainly (for me) there’s the benefit of not having to do anything special with the material setup inside the xna application. Everything just works, textures follow through and are assigned automagically, and the same with all material properties.
So, it’s very practical from a get-things-working-without-doing-much-code point of view :slight_smile:

We do have a script based material system at work as well, and yes there are advantages and disadvantages. The advantages are of course to be able to tweak the material in the 3dsmax viewport. The disadvantage is of course that you have to be very careful to make sure the in-game shader is synced with the 3dsmax shader. We’ve had some cases where these two behaved differently in some respects and it’s not a good thing. Having a single “super-material” is in a way more limiting than the node based approach, but perhaps easier to control. Maybe something inbetween the two would be a better approach.

And the biggest problem is that the .dx materials perform really badly if you compare with standard materials. It’s quite tragic really, and to my knowledge there’s no change since the .dx material was first introduced. A good idea, but it doesn’t fully work in practice, since the performance is so low. :confused:
So, you need fallback-to-standardmaterial to fix this somehow.

I guess the optimal would be to be able to edit materials fully in-game, as there’s becoming more and more material/game specific features which are hard, or impossible to do from within 3dsmax.

Kjetil.

主任告诉他们,打呼噜是许多人睡眠的一个常见现象,但当鼾声超过60分贝时就会对周围人群造成明显的干扰,这就是一种病态了[b]儿童鼾症[/b]尤其要引起警觉,多数是一种病态。打呼噜乱动、呼吸暂停、易梦易醒、头晕头痛、情绪紊乱、注意力不集中、记忆力差、易疲劳、嗜睡及咽喉干燥等都是[b]小孩鼾症[/b]的常见症状。主任说,鼾症的发生主要是由于鼻腔、咽腔、喉部气流不畅而致软腭、舌根部的剧烈振动引起。经检查,王鹏的[b]扁桃体肥大[/b]、腺样体肥大。这是导致他咽喉、鼻腔气流不畅的主要原因。他表示,鼾症危害很大,要尽快[b]咽炎的治疗[/b],否则后患无穷。有些问题现在还看不出来,如任其继续发展,可引起高血压、心律不齐、室性早博、阻塞性肺部疾病、呼吸性酸中毒、紫钳,甚至呼吸骤停等。其实,[b]打鼾治疗[/b]起来也不复杂,只需要运用低温等离子“消融”肿大的组织,几分钟内就可迅速解除鼾症的烦恼。