Translucency issues

I guess this is still somewhat on the issue, but has anyone else had problems with 3DC Pro displaying translucent textures? andnbsp;On my baggage car, i am using some heavy tinting on the windows, and just for a test, i have a really dark color on the Alpha channel and a really light gray next to that. andnbsp;I split the alpha channel into an 8-bit .bmp. andnbsp;When i use this as the translucency map, the light gray area is not translucent at all – it is completely opaque. andnbsp;I tried several different translucency values, all ended up doing the same thing. andnbsp;I even changed the bitmap to a 24-bit, same thing still happened. andnbsp;Am i doing something wrong with the bitmap itself? andnbsp;Could this be related to the problem?

Mike,

That was more of a andquot;hmmmm, I wonder…andquot;, but thanks for the answer.

Richard

Richard,

Can the fellow who did the 3D Studio Max Object for you re-do it using AlphNorm+ for the material name?
Train-sim.com had a post where someone using AlphNorm for the material name had the same problem we do, but claimed using AlphNorm+ instead fixed it. andnbsp;Just a thought…

I just decided to take the Scotsman 3ds sample file through the Kuju conv3ds utility and install it it the ‘game’. It was a lot quicker than taking it through 3DC – but guess what.. even though the cab windows were translucent, no world objects were visible through them, except for the usual track and landscape.

Richard, I noticed that the Kuju files are using BlendATexDiff rather than BlendATex for the cab window texture. I tried editing the 3DC output, but found no difference. I somehow suspect you’ve already tried that though. <!– s:) –><img src="{SMILIES_PATH}/icon_e_smile.gif" alt="" title="Smile" /><!– s:) –>

Mike

Richard,
I’m not sure how significant the 3ds file experiment really was. There is only an AlphNorm defined in the file, no pluses or minuses. I’ve been trying to modify it manually. I thought I had once and the file went through the Kuju conv3ds, but screwed up in the DirectX SDK one. There was no difference in MSTS, so not sure what I really changed. I’ll try again tomorrow, when I’ve had some sleep.

You didn’t tell Buzz if you got any differences for the different materials I agree about the SDK, but I hope it is better documented than the current notes on the subject.

Mike

buzzbenz,

He provided me with all of the materials, including the pluses and minuses.

Richard

Mike,

Now THAT is interesting. I wonder why. It sounds to me like their CONV3DS.EXE doesn’t work properly. Maybe they do something to the resulting S file manually? I am very curious to know exactly what. But until there is an SDK we probably won’t know the answer.

Richard

Quote:

. . . Richard, I noticed that the Kuju files are using BlendATexDiff rather than BlendATex for the cab window texture. I tried editing the 3DC output, but found no difference. I somehow suspect you’ve already tried that though. <!– s:) –><img src="{SMILIES_PATH}/icon_e_smile.gif" alt="" title="Smile" /><!– s:) –>

Mike

From my experimenting with the .s file, I’ve found that (I’m pretty sure) that the andquot;Diffandquot; on the end of the shader name indicates that the texture should be lit appropriately based on the game environment (light source, etc.). Without the andquot;Diffandquot; the texture is always bright, the effect you might want for the inside of cars or cabs, or anything you would want to be bright all the time, even at night. This is the problem that people got when they switched to the newer versions of 3DC, and all of their objects showed up really bright at night. By setting the specularity material value in the newer versions 3DC to a nonzero value, it adds the andquot;Diffandquot; to the shader name for the texture.

I believe that’s the way this works, anyway <!– s:-) –><img src="{SMILIES_PATH}/icon_e_smile.gif" alt="" title="Smile" /><!– s:-) –>

troub,

Yes. That’s exactly how it works.

Mike,

There were no differences due to prioritization on simple objects. No doubt there would be on more complex models. But since this can never be implemented with 3DC it isn’t really an issue (see the 3DC MSTS tutorial/documentation)

Richard