Right now I've got a model which has a transparent texture for the eyes which works fine in 3ds Max (http://i.imgur.com/2JpwOm2.jpg), but gives me trouble when imported into Source. (http://i.imgur.com/2bNd1cT.jpg)
Here's the associated export settings with Wall Worm Pro: http://i.imgur.com/4HaND36.jpg
And here's the .vtm and .qc files: http://i.imgur.com/qTdxyZY.jpg
Any help to fix this would be greatly appreciated.
Can you post a picture of the Material setup in Slate as well as the Bitmap settings in the material editor for the eye bitmap?
Still somewhat new to 3ds, so I hope these are the correct things you need:
Material setup: http://i.imgur.com/Ky8Ta0E.jpg
Bitmap setup: http://i.imgur.com/z0HOVk0.jpg
Did you make sure to check the $mostlyopaque command in wall worm's export window? If set to $opaque only the transparency will not come through.
Have you set the DTX settings? Either DTX 3 or 5 should work. I tend to go with 5. Being a WW noobie myself, it gives me the least trouble.
Also, I think you'll want to use $translucent "1" instead of $alphatest in the VMT there. Alphatest is a command that will give the texture rough edges but translucent should fix this. Be careful with translucent though. There is a rendering bug with it in the source engine that'll made translucent textures fade away if exposed to certain lights.
I did go with DTX5, and $mostlyopaque is checked. You can see so in the third image I linked in the original post. I changed it to $translucent "1" with no results, unfortunately.
Quote from: Sigmous on July 12, 2016, 01:47:17 AM
I did go with DTX5, and $mostlyopaque is checked. You can see so in the third image I linked in the original post.
Whoops, you're right. I didn't see that before.
Have you made sure to also check DTX settings in the wall worm texture properties part when in the material editor? It should also be checked there, if I remember correctly. Here's a picture from my scene.
http://i.imgur.com/iR4jxkp.png
So I was looking at your picture and realized that my textures and materials didn't have that 'Wall Worm Texture Properties' tab on the side, so I went through the toolbar and found it, added it to the materials, and then changed the compression on the textures to DXT5. Voila! - http://i.imgur.com/4E0CHfW.png
Thanks so much for the help. Just in case I'm potentially not seeing it, is there an option on the material or texture parameters for enabling $alphatest or $nocull without having to go into the .vtm file itself to enable it? I found that $translucent was causing some 'see-through' issues (http://i.imgur.com/VpWvoF6.png) on some models, that was resolved by switching to $alphatest instead (http://i.imgur.com/ftLS6LA.png).
Yay, I helped! \o/
As far as I'm aware you do have to change some commands in the VMT. It's not a biggie though. :) If you're like me, being the person who really dislikes looking at codes with a passion, you can keep a list around of the commands and describe what they do. Makes it easier to keep track.
As for $translucent, yeah, it's known to cause some issues when rendering. I ran into problems myself with that quite a few times. One such issue was that translucent textures would keep fading away under player-added lightsources, which I covered here: http://steamcommunity.com/workshop/discussions/-1/357287935563132751/?appid=1840&tscn=1465331510
$alphatest should work for this tent-like model though, since the texture is fully opaque on some parts and fully transparent on others. $translucent is for textures that are partially transparent/opaque (anything in the grayscale range between 255 and 0. Think of stained glass for example, and the glow on the eyes of your character.)
Okay, so... this might be off-topic for the thread since the problem was resolved, but I didn't know if I should just make another thread so soon... but I've tried solving this problem for the past hour or two. It's been recurring, even before the transparency issue. And it's like the last thing I need to beat. My model is stretching and distorting whenever I try to manipulate the limbs, like so: (http://i.imgur.com/WLPK5kI.png).
Whenever I move the object highlighted on the right side (humanmale-model), the distortion will move with it - like so: (http://i.imgur.com/n7fYjrl.png)
Glad you solved it.
WW will not add $translucent or $alphatest to a VMT if the diffuse bitmap's settings are set to None for Opacity. Once changed, WW will use $translucency unless the Material has the $alphatest checkbox on--and notice the setting by it for $alphatestreference. The video below should give you a good understanding of controlling alpha straight from Max:
https://www.youtube.com/watch?v=WnmEWVo7k18
In terms of the stretched skin, it's got some vertices that aren't weighted (or are not fully weighted). Open the model's Skin modifier and fix the weighting for the vertices that are not working correctly.
This probably sounds dumb, but Shawn, have you ever considered creating a checkbox list of some kind for all of the $ commands? Would be handy to have them all in one place and just check which you want to use. so that they'll show up in the VMT once you export them. :)
It's just a silly late-night thought.
A very large percentage of the VMT commands can be controlled in the material editor if you add the WW Shader custom attributes to it (http://dev.wallworm.com/document/123/source_shader_settings.html).
Some, like $Alphatest/$Translucent I specifically left tied partially to the bitmap node's settings because the validity of those settings is dependent on the bitmap nodes. Bitmaps that do not have an alpha channel or those set to DXT1 cannot work with those settings... and I think that it helps see how things work in that case by needing to set the appropriate bitmap settings.
Others, like $basetexturetransform (and other transform params) are controlled by the bitmap coordinates of the bitmap nodes (otherwise you could make a change in VMT and not see what is going on in Max...) and since setting it visually how you want in Max just makes sense... that is why those are controlled in the bitmaps and not in the material (although whether or not the VMT outputs the transforms is dependent on the Material's setting for outputting texture transforms if the WW shader is added to your material--because the WW SMD/DMX/VMF exporters natively take into account these transforms in geometry... meaning that there is no need for them in the VMT with a WW-only workflow.
I'm very suspicious of these model exports... I'm getting the jagged edges for every single model that I've exported from the WoW Model Viewer thus far, and that shouldn't be. I honestly don't know why and I can't imagine that the weights of every single model are off, but I can't find anyone else who's had this problem. Very frustrating.
I've noticed two things:
- The jagged edges move when a specific bone does... In this picture (http://imgur.com/9m0PgEk) you can see that 'nightelfmale_hd' is ahead of the model, and whenever it moves, the jagged edges will stretch or shrink in that direction. It's invisible in Source Filmmaker, but it associates with the name of my mesh in 3ds max.
- Bones are being deleted during export. I don't know why, but they are. Some of the bones present in 3ds when I import aren't there when the model is moved into SFM. And some of the bones which are deleted are related to the areas where the jagged edges are present. Is there any way to preserve all the bones on export?
Any idea if these would be responsible for anything?
Bones missing... not sure how that can happen. Click File > Save As... Archive and email the ZIP file to me. I will investigate. It could just be the MDL compiler. Often studiomdl.exe will remove bones that are not actually necessary (for example, if a set of children bones are never animated in their parent space). But that is not a WW issue--it's the way studiomdl.exe works--although there are usually some QC commands you can do to force them to stay.
Normally, if a model has stretching like the image, then it means that the skin weights are wrong inside 3ds Max. If there are missing bones, that could be a culprit, but considering the fact that the image shows only a few individual verts stretching, it looks more like bad weights than anything else. I've been sent files like this many, many times over the years and it's been 99.9% bad skin weights.
Hey, I couldn't find an e-mail readily so I used the e-mail form on the site. You can find the model here as well: https://mega.nz/#!LV4niAAA!ZXeeORy55MCz9JENvcsoYC1DbZq2XKJ95xDlhIEQ0tc
When I opened the model you sent, I guessed the problem right away. The OpenSubDiv modifier on top of the Skin changes the topology of the mesh... and even though it works right in Max, it can create values that are not actually true to the exporter. Best to never change the topology on top of a skin modifier if you can help it. When I exported the scene directly, I saw the stretching on some verts. When I disabled that modifier, the stretching was fixed. See the attached image.
Note that even though your OpenSubDiv was set to 0 Iterations, it was sending incorrect values to the mesh-reading functions in Max for reading.
If you have to add more resolution to the mesh, you may want to experiment with TurboSmooth, TurboSmooth Pro... or simply resign yourself to re-skinning the mesh after you are done... as the OpenSubDiv modifier is providing incorrect data to the system on top of a skin modifier.
Thank you... so, so much. I just imported three models into Source Filmmaker after removing the OpenSubDiv and it relieved the problem instantly. I'm not even sure why it's there, I didn't add it - it must just be defaulted on there after importing from WoW Model Viewer. I'm still testing but nothing out of the ordinary has occurred yet. This is fantastic. Thanks SO much. I would've never suspected that modifier.