Wall Worm Forums

Quote from: Pipann on September 08, 2022, 09:43:37 AM
Hi Joris, thank you for the comprehensive post, but I think you missed my point. Perhaps I wasn't really clear enough.

Since Max 2021, the material editor traded Standard Material with Physical Material and Arnold, (as stated here in their documentation https://knowledge.autodesk.com/support/3ds-max/troubleshooting/caas/sfdcarticles/sfdcarticles/Standard-Legacy-Materials-don-t-appear-in-3ds-Max-2021.html ) and it no longer has the the old material options available (in 2023, the version I use now, standard material seems to be completely removed, as I'm unable to find it when trying Autodesk's solution). Using the 'Give Obj/Tex WW Materials' option did not seem to change anything for me in the material editor either.

However, your answer still provides a solution. I'll start using the normal map's alpha and add the phong parameters manually in the vmt's afterwards. Thank you! ;D

I somehow missed the point of Arnold as a renderer, however I'm pretty sure they haven't removed the Standard material. What they did do is make Arnold the default renderer for Max as opposed to the Scanline renderer. If you aren't seeing the 'old' materials and maps inside your material editor, go to the render settings and change the renderer from Arnold to Scanline. Now they should re-appear, but ever since Max 2023 they're now put under a different rollout just below Arnold (I think) and it's now called 'Standard (Legacy)'.

There's no way they would ever remove Scanline and the standard material node, but they are trying to push people to use Arnold for everything now to get them to learn it. It's a great renderer (and required for AO-baking), but for most Source-uses you just want to use the legacy standard node.

Also note that the article you linked to states that Arnold itself is not compatible with the old legacy materials, but that doesn't mean they were removed. Now you just use Scanline with the legacy stuff, and Arnold exclusively with Arnold.

$phong is determined by settings inside the Standard Material node that contains all the information (both the default settings from 3DS Max as normal, as well as all the WW-Source specific stuff from Wall Worm once you've added material and texture parameters, which you can do by going to Wall Worm -> Wall Worm Materials -> Give Obj+Tex WW Materials). Please note that Wall Worm will automatically do this if you hit the Export VTF's button from the Wall Worm Model Tools floatable menu).

To simply add $phong to your .vmt parameters, you can switch the Shader Basic Parameters at the top of the material node from Blinn to Phong and you're set:


If you need more specific $phong settings, you have a dialogue box just for that a bit below, among many other settings:


Please note that for $phong to work, you need to have a roughness/specular mask baked into the alpha channel of the bumpmap. If not, it needs to be added to the diffuse's alpha channel, for which you have the options as seen in the image above :) (Wall Worm may or may not automatically detect this and already adjust the options for you, but I don't know for sure. I always use the normal alpha channel). For $phong settings on brush materials or for using $phongexponenttexture I don't know the specific details. Best is that you ask Shawn, the author of the plugin, for more information.

Good luck, and let us know if you need more help or information!

Quote from: lauris47 on May 30, 2022, 03:26:15 AM
Is it possible for you to do the update on WallWorm plugin?
I know you are probably busy with Autodesk and stuff.

There are probably other ways I can try to get this channel out, but it would be most comfortable via WallWorm.
I tried MilkShape, MESA for Maya, also Valve's Model Viewer . No luck. I will try HammUEr for Unreal now. There is also some Blender method, that I am not familiar with yet.

I know it's been a while since you replied, but do I understand it correctly that you are still trying to get the original second UV-channel from official Valve models? I'm really not sure if it's possible. You could actually do an update that allows this, Shawn?

Quote from: wallworm on April 04, 2022, 10:08:04 AM
The revision I was planning in 2019 never happened because I got entrenched with my work at Autodesk. It's now been five years since the last revision to Hammered to the Max and the document is getting very dated. I would really like to make a revision this year. As such, I want to make a call-to-arms for Max users to share screenshots of their projects that utilized WW. I would love both Max screenshots as well as final productions in-game. If you would like to see your work in the next edition of Hammered to the Max, please send me your screenshots of Max/WW and in-game work, along with a note that you give me permission to use the content in the publication.

I'm working my a** off to get Daigo released for the next version. Once again, a number of interiors needed more changes than I expected (especially geometry-wise), although I've finally gone through all the lighting techniques for getting exponentially better indoor results. I can't promise immediate screenshots for the coming week(s), but sometime in July I'll be able to provide screenshots. Would that be alright?

You actually installed Windows 11? I'm too afraid to do that yet, as I know from a number of programs that they don't work properly yet... I'm gonna wait regardless and perhaps install it a few months from now (or next year). Thanks for the walkthrough, though. I'm sure a number of people will run into this problem!

 :o

Hey!

I'm not sure what your specific issue is, but CS:GO itself has a material parameter that allows any kind of texture (known as $decaltexture) to be displayed on top of the $basetexture through, as you mentioned, a second UV-channel. This will really only be displayed correctly in-game (and not even in hammer in some cases, making models look black in the editor but correct when you're in the map). As far as I can tell, in 3DS Max when you import the model from either an .smd or .mdl the information for that second UV-channel is lost. Currently there exists no fix for that and I believe it is Valve only who can add support for this. I even think it was already requested several times, but I don't know if they are willing to provide this support  :-\

If you need to recompile an existing Valve model (from any game, really, since the second UV-channel info gets lost regardless upon import), you will be required to reconstruct a second UV-channel and see for yourself how it displays in the viewport inside 3DS Max. What you see is then what you'll get if you export your materials correctly. To do this, however, you will need to tag the 'Export FBX' flag in the WWMT settings for your object, else the second UV-channel will simply not export.

More detailed answer to your question can be given by Shawn, but hopefully this somewhat answered a few of your concerns! 

Quote from: rtokuda on December 30, 2020, 04:40:27 PM
It is in the 512x512 dimension

If you're trying to export the textures from 3DS Max to Hammer, make sure that the .vtf's are having at least DXT3 or DXT5 as compression method for the alpha (aka Eight-bit-alpha). You can change this in the bitmap parameters in the Wall Worm Texture Properties rollout (see image). If you don't see this rollout, generate these settings by going to Wall Worm (menu) -> Wall Worm Material -> Give Obj Mats+Tex WW Materials.

You should now see those options and be able to change the compression (DXT3 for 'sharper' alpha's, DXT5 for all other purposes), and then re-export the bitmap and .vmt to overwrite the old settings. For the vmt this means it will now include either $translucent or $alphatest to enable transparancy in Hammer and in-game.

Quote from: wallworm on September 03, 2020, 06:57:42 PM

• ambient_generic
• env_physexplosion
• physics_cannister
• trigger_proximity

No problem!

Quote from: wallworm on September 02, 2020, 07:39:50 PMI want to try and get an idea about how many people this will affect as well as how many scenes. I need to know if it's worth my time to built this function.

For me, specifically for Daigo, won't be a problem because I hadn't any ambient_generic entities. Not sure about other entities (prop_static also have a radius option for visibility optimization), but I'm 100% positive I haven't dabbled with any of the radius values on any possible entity in my scene, aka they're all the default as it is in Hammer.

Do you have the latest version of Wall Worm installed (of which the Pro version is now entirely free!)? If so, importing the .mdl itself through the mdl importer or generating a wwmt helper through a prop_static entity will normally yield the original collision model of the prop. However, this collision model is often hidden by default or even hidden in a seperate layer, so make sure to unhide any hidden objects or layers that possibly contain the collision model. If this model didn't have a collision model to begin with, you'll obviously lack one even when importing properly into 3DS Max. If you're getting one large hull from the Hull Helper, it means that the object of the model is made out of one element (which you can check by going into Element mode, or pressing 5 on the keyboard for the shortcut when you've got the model/editable poly selected). If you want to create a hull that matches your model more accuratly, try seperating the object into multiple elements instead.

There are probably even better ways to generate a hull from the Hull Helper, but I don't remember all of them off the top of my head. If you prefer, you can create a copy of the imported model, and seperate it into multiple elements before actually generating a collision hull. In that case you don't need to break up the imported model and you can experiment more in case you need more accurate results.

More information can always be found here: https://dev.wallworm.com/topic/19/hull_helper.html

That looks pretty cool!  8)

Quote from: jrocket on August 18, 2019, 10:47:14 PM
I was able to solve this by untagging the suspect brushes as world geo, and re-tagging. Not sure what was going on there.

Rarely, this may happen if you have geometry that has other modifiers on it (= more than one Editable Poly, additional UVW Maps and/or other modifiers). I have this specific case where I have to actually tag it as being Concave and Brush Geometry again after I had done some changes or added modifiers. However, for me it was that the geometry was simply not being exported at all, not offset like in your case. Geometry that gets off-set during export, compared to what you see in 3DS Max is almost always a result of the origin being changed during editting the object (pivot moved for whatever reason). This is always fixed by applying a Reset Xform.

You're saying that all you did was untagging the object? (= 'Do not tag this object as World Geometry') and then tagging it again? Are the arches made with the Arch plugin by any chance?

Quote from: Pocket on July 30, 2019, 01:47:02 AM
Re-saving as BGR888 and rebooting 3ds Max did the trick. I think from now on I'm just going to use alpha-free versions of the textures for when I build the prop in Hammer, since I'm having to use a separate copy anyway that's outside of /materials/models/. I'm certain that way back when I started this project (using 3ds Max 2013 and whatever version of Wall Worm was available back then) it didn't matter, but it was also so long ago that I have no idea what the process was like.

Glad to hear you've been able to solve it! Just out of curiosity, since I assume this model will be used as a prop_static... but why are you using this format? It's file-heavy and is almost never used by Valve for level design (mainly on weapon textures, if I'm correct). In the very early days of mapping, I dabbled a little with different texture formats, but never saw any significant difference, if at all. I had heared on forums about people saying it saves the colors better etc, but never saw Valve using this format, ever.

In this case, I would simply suggest you convert your texture into the DXT1 format. I can't possibly believe that the RGBA8888 format would cause an error, but since I never ever use this format (you should never, for prop_statics, in my opinion) it could just be the reason. Then try importing it again, and see if it comes through. As Shawn already stated, if your textures are missing upon import, UV's may be invalid. Since yours aren't coming through, aka black as can be seen in your screenshot, it's most likely the reason for error.