Wall Worm Forums

Kevinlongtime wrote:

Thank you so much, both Wunderboy for taking the time to explain and re-write the normals export code and as always Shawn for helping out!

I haven't been able to test it as of right this moment becuase I have Max 2011 32bit (shouldn't work, right?) but from what Shawn has mentioned about the FBX file I sent him working on export now sounds very, very promising! I'd love to give it a test !

As for trying out the option for alternate normals, I don't recall the window popping up during normal compile with model tools for options such as clicking alternate normals so idk how i'd do that:S. Though, I'm guessing I should just wait anyways for the test built since you have already re-written the code for the next release?

---

YES!!!! I have just recieved the test version of the plugin with the new export normals code courtesy of Wunderboy (and Shawn for relaying messages) and it works beautifully. Seems to work perfectly even when importing OBJs now! Thank you once again Shawn for sticking through trying to help and contacting Wunderboy and Wunderboy again for re-doing the code which seemed to do the trick:)!

Well, that hurdle seems to finally be gone. Feels like some creative freedom now

Here is how the model from TF2 that I was testing is looking like in the source engine now after compile (like it should, smoothing wise)

Wunderboy Wrote:
I don't have an answer for sure but I've seen this behaviour before. The same sort of thing happens in 3DS Max when importing an SMD with my import plug-in and then re-exporting it.

See there are two ways of setting smoothing in Max - explicit normals where you set each vertex normal individually or Smoothing groups where the normals are calculated for you based on the smoothing groups of the neighbouring faces on the current faces edges.

Most people use the smoothing groups option and set the group automatically or explicitly for each face as it's just easier and goes better with the continuous mesh ideal. However might importer uses explicit normals as that's how they are defined in the SMD and as of yet, I haven't found a quick way to rebuild the smoothing groups from them.

However, with explicit normals it's often easy to destroy the smoothing by making changes to the base geometry. In fact in various versions of Max I've found that even adding some modifiers to the stack can destroy the smoothing which is a complete PITA.

My own experience with OBJ files is that they too produce junk half the time and the results are largely down to the quality of the export and importer code that handles them. 99% of the time any OBJ I've tried to bring into Max ends up with one smoothing group (to rule them all).

FBX I've had better luck with but at the end of the day - it depends on how they handle normals. I think FBX uses smoothing groups like Max but if you're using explicit normals that could be where the problems lie.

The SMD exporter does actually have a "Use alternate normals method" option which uses different code for exporting the smoothing. By default it looks for the auto-generated normals from the smoothing groups but if you've got explicit normals, these don't export and you get a faceted looking model. That's when you should try the alternate normals method. That looks for explicit normals and exports those instead.

It looks to me a lot like you're suffering from the visual normals being OK between Maya -> Max but the underlying normals definition is not being picked up by the SMD exporter code. Try the alternate method and see if it make a difference.

I have found the problem.

Even though the model looks smooth in the viewport, it doesn't actually have any smoothing groups at all. NONE. I assume that it isn't actually translating in from Maya to Max via FBX... but as I know nothing of Maya it's hard to predict.

You can tell this by selecting face sub-object mode and selecting faces... and in the command panel scrolling down to the smoothing group section... there are no SGs assigned to ANY faces. They look smooth either because of their actual orientation and/or a viewport setting.

Not to worry. I have a fairly quick solution for you.

Go into Element Sub Object mode and select each Element one at a time. When selected, scroll down to the Smoothing group section and choose Auto Smooth.

It may not produce 100% of what you want but from what I did with you model (which has 2 Elements -- the body and the base), it worked flawlessly. If something isn't just right, then you can go into face sub-element and specifically assign SGs.

Attached is a screen shot as reference. (Far left is inside HL Model Viewer after this process and exported).

Kevinlongtime wrote:
Ohh alright, I see what you mean, and it looks like I was using v1.5 but I have now upgraded to v1.6 and the same thing occurs.

Thanks for fowaring it on to them! Much apprecited

Also, I'm not sure if this helps but I used to use a program called milkshape (when I compiled manually) to get the smd and then use GUIstudio to compile and get the model to source and this was via the old way of how I used to do it by exporting an obj from maya (which would lock the normals, same thing) and import into milkshape and those models never had an issue with smoothing in the end. I dont know/remember what sort of smd exporter milkshaped used though.

Skipping Ahead in old Conversation:
Very interesting.

WWMT itself never even considers smoothing groups. It is the SMD exporter that handles all that. In WWMT, the only time Smoothing Groups are touched are when you press the Process Hull or Prepare Hull buttons... and those are really only to help add smoothing groups to collision hulls if it is $concave. In terms of WWMT, the only thing I could think of is if you assign a model than pick that same model with the Hull picker... and use the process hull function. In that case, WWMT would assign each Element of the object a unique smoothing group... but even in that fringe case, I can't imagine your model would be such that each face is its own Element sub-object.

(BTW, it's generally not recommended to select your model as the collision hull... just for anyone new reading this thread. You should make a separate model as much as possible.)

It may be something else... perhaps too many smoothing groups? (I don't know if Source has a limit..)

Anyway, I'll forward this thread to the SMD export developers (Wunderboy and Canonfodder) and see if they have any input. Which one are you using?

Retrieved posts from Google Cache.
Kevinglongtime Wrote:

Hey all,

I've been having this issue that has been bugging me where my models arn't keeping the types of normals-smoothing i've been giving them in Maya (as you can tell this question I dont think pertains to wallworm itself).

I use Maya for all my work and I use 3DS max purely for this export tool. Long story short, when I import the final product from maya > to 3ds max > to source, the results turn out being that everything on the model is now smooth regardless of what I had manually did myself in maya. So that means all the hard edges on a cube, for example, would look very odd and smooth.

I never had this issue when doing it the regular way of compiling so I think this issue boils down to the bringing over of models and maya's own way of smooth over to 3DS max (If I read right, 3DS max has an entirely different way of smoothing and its called "smoothing groups").

Anyone have the knowledge to shed light on the best way of going about this so that it retains my set normals smoothing while transfering? The odd thing is, in the viewport of 3DS max, the smoothing seems fine but when it gets to source it looks all messed up. I am self taunt in using these program so I may be missing what some of you may consider an obvious option or file type for exporting or even an importing option for 3DS max. I've been mainly using the .obj format with the normals option ticked to bring over the normals smoothing.

This is how odd the flat surface on my stopsign is looking in Source model viewer becuase of all these edges getting oddly smoothed

So I have been testing this new version and feel I can leak the beta... there are still a few things that I plan on adding to this version and it's not fully tested... but if you are daring you can install this version and provide feedback:

BETA DOWNLOAD REMOVED... 1.7 is now out

REMEMBER IT IS A BETA! If something is majorly broken, you can always download the official version from the main site.

For this version it is important to run the Add to Menu button in the WWMT settings after you copy this version. It will add a couple new macroscripts that are part of this update.

VTA Tools
The new VTA features are this:

1) WW Morpher UI. You can find this after updating the WWMT menu under Wall Worm > Wall Worm Utilities > WW Morpher UI. At the moment it's just one button.

What does it do? For each mesh in the current selection when you press the button, it will find those that have either a Morpher Modifier or a Morph-O-Matic modifier. It will then create a keyframe for each channel at 100 weight (and put the rest at 0 for that frame). This speeds up preparing a morphed mesh for VTA export.

2) VTA Exporting. This function will only work properly if you have Wunderboy's VTA Exporter installed. (I'm not even sure that it checks at this point... so make sure you have that before testing. If your WWMT mesh has a morpher, WWMT will export the VTA during export and will create the flexfile code for each channel in the morpher. At the moment this code is included in an external QCI file that gets written alongside your main QC. There is also a custom QCI flex file written alongside both of these... the intent being that the custom file will never get over-written by WWMT once created.

The process still takes more to get full flex to work... but this is a stepping stone at the moment that should help speed up the process.

PARTICLES
WWMT now lets you assign particles to your model. You can either use from the preset particles for the mods I've added into the tool (CSS, HL2:EP2, TF2, L4D and Portal) or you can enter your own custom files.

You can assign all the parameters to the particles such as which attachment to use, whether it is in the keyvalue block, or assign it to a frame in a sequence.

I'm sure the kiddos will love that one.

MORE

Another new feature is that all QCs get a line added to include a custom QCI file that you can use to add custom parameters not in WWMT. That custom file will get created alongside your main QC and will match the name of your model's QC file except it will say _custom at the end and have the extension .qci instead of .qc. (This is a separate custom QCI from the one mentioned above... which is for the flex data.)

Also, you can now set $reflectivity with the Reflection map of a Standard Material. Use the spinner for percentage... or use a Color_Correction map in the Reflection slot to set a color.

Please send feedback. Right now my main focus is feedback on optimizing the flex/vta process. If you find a bug, please share it in the bug report section.

Version 1.7 is out. It's one of the biggest single updates I've released. It adds many new features, fixes several bugs and changes a few things.

At the moment, I do not have any additional documentation on the features listed below. The changelog description is the only docs until I get time to explain them in more detail. I expect to make a video soon demonstrating Sequences, Attachments and Particle Systems.

Please make sure to report any bugs!

Version 1.7 released on 09-27-2011

•Added VTA export for models with a Morpher or Morph-O-Matic modifier. A flexfile with the channels is created and linked from the main QC. Currently only works with the Wunderboy VTA Exporter.
•Added VTA-Prep function to automate the creation of keyframes on meshes with Morpher or Morph-O-Matic modifier. This item is the WW Morpher UI in the Wall Worm > Wall Worm Utilities menu. It makes keyframes for each channel in the modifier. (If you don't see it, you can add it to your menu by opening WWMT Settings and clicking the Add to Menu button.)
•Added Particle System UI in the Attachment rollout to allow attaching particles to your model. Many particle systems in popular mods are available from a menu; also add the name of your own custom system.
•Added new line to all exported QC files for an auto-generated include QC file. If the include file isn't there, WWMT will now always create it. If it is there, it will not over-write it. The new include is always in the same directory as the current QC. If your model name is "mymodel" the main WWMT QC is called "mymodel.qc" and the new custom QC file is called "mymodel_custom.qci".
•Added support for Reflection export as $reflectivity. Uses Reflection value, or if your use a Color Correction Map (Max 2009+) in the Color Correction Map, uses the Color of the Color Correction map.
•Added $ssbump to export of LightmappedGeneric and WorldVertexTransition materials exported with the Displacement tool. ($ssbump is not supported on other shaders in Source.) Will automatically use $ssbump on such materials that have an alpha channel in the Normal Map of a Normal Bump.
•Added replacemodel and replacematerial to QC for bodygroup models that have LODs. Now main model QC will swap out LODs of bodygroup models automatically.
•Added new WWMT setting to turn on/off the export message prompt for models and model textures. That message prompt now defaults to off... which is convenient especially with models that have multiple models (ones with Bodygroups or custom gibs) and the batch exporter in the Utilities rollout.
•Added Del Sel buttons to LOD entries to let you remove a mesh from that particular LOD.
•Added Material button to each LOD entry into the LOD list. This lets you assign a material for that LOD that will over-ride the materials when at that LOD. Note that the function only works for materials that have a name that has a diffuse TGA that matches the name of the root model's TGA(s) and follows this pattern: if root model diffuse TGA is "mydiffuse.tga", then the material will only be swapped if you also make a material with a diffuse map having a "mydiffuseLOD1.tga" in LOD 1, "mydiffuseLOD2.tga" in LOD 2, etc. Accepted materials are Standard, Multi/Sub-Object Materials and Shell Materials.
•Changed $phong no longer exports for any Shader type except for VertexLitGeneric.
•Changed Diffuse Bitmap now optional. If none supplied, diffuse color is used in the VMT as $color. Note that this feature seems to be best used on the Lightmapped Generic and UnlitGeneric materials... when used in VertexLitGeneric... I have not been successful in getting the color to work... but it means you can compile a model and view it in Source without a texture yet... though it will be white or gray in-game.
•Changed Displacement tool VMF exporter to use prop_dynamic for any model that doesn't have $staticprop checked and has no Prop_Data assigned in the gibs rollout.
•Fixed export bug when exporting a model that had bodygroups assigned in a previous session.
•Fixed Bodygroup materials not getting exported with the main model.
•Fixed gibs materials not collecting recursively on main model material export... now it should collect all of the gib's decendant materials.
•Fixed Export bug that happened if any of the materials in the Skin material were not Standard Materials with a diffuse bitmap.

So I've gotten a few emails from users. I'm glad everyone seems to like it.

I just want to quickly address a couple of the most common observations/questions.

1) Going into Edit Mode can take a while (sometimes a couple minutes). This is a result of the way the sculpt mesh is created. I already have a solution lined up to make that go faster... but doing so requires some re-writing. I may also consider learning a little C++ to make it even faster than what I already have in mind. I cannot give any kind of ETA on when I can address that... but hopefully next week.

In the meantime, the solutions are to use less displacements and/or use lower power (2 & 3 as opposed to 4).

2) You cannot copy a displacement (you always have to use the UI to make a new one). That is also something I intend to address in an upcoming update.

Version 1.0 is out. Here's an overview video:

Sorry the forums have been down for over a day. Our server hard drive failed. Worse, I hadn't been backip up the forum database like I should have been. Luckily there is a little bit of a site here... but there is a ton of information that is now gone. Oh well... at least all of our clients' data was backed up... as that could have meant the end of all things Wall Worm!

Anyway... Version 1.71 is out now. I'll explain more later as I'm still getting all of our domains back up and running. I'll load a new video to Youtube tonight or tomorrow with the main new additions to the world of Wall Worm.

So I have started the groundwork for adding VTA support. Cannonfodder has already sent me an updated VTA exporter that has MAXScript integration... but there are problems at the moment. I'm not certain if/when Wunderboy will have time to do the same.

In any event, I expect to have a beta of this in a couple weeks... so anyone who wants to help test it when ready should let me know... since this is an aspect of Source I'm not really familiar with and will need testers before I actually release WWMT with VTA support. Preferably those who have experience doing facial animation in general and/or for Source.

I'm adding support for the standard Morpher modifier as well as Di-O-Matic's Morph-O-Matic (since I own it and am familiar with it). If there is another facial rigging system anyone wants support for, let me know. If it's free I may consider adding support; for commercial one, I'm not likely since I've already got Di-O-Matic's tools and unwilling to pay for another.

I noticed today when running a texture export in Max 2011 that there were two (2) VTEX Dos windows for each VTA being exporter. I'm assuming that it's from the patch I added for the 2012 Filestream lock bug . Since Autodesk fixed that bug I will remove that patch soon.

This isn't a critical bug... as the second console will simply tell you that the VMT already exists. It's just an annoyance since you have to close twice as many windows after compiling. I'll fix it in the next update.

Quote from: Fletch on May 15, 2011, 09:43:11 PM
I'll have to check out 2012 today! Do all of your plugins still work properly with it?

Yes, my tools are now compatible with Max 2012... but not all things are yet supported.

Cannonfodder has updated his SMD Exporter for 2012.

Wunderboy has not yet got his SMD Exporter out for 2012 (a few features in WWMT only work with the Wunderboy SMD Exporter... so for those [Exporting Non-Renderable Mesh as Bone]) you'll have to wait for his update.

Quote from: Fletch on May 15, 2011, 10:30:58 AM
Amazing stuff!

I just got into mudbox today. Love it! Interface is much friendlier than zbrush

Thanks Fletch!

Yeah I tried out ZBrush and Mudbox at the same time three years back... I tried ZBrush first since it was the "industry standard". But I found that I wasn't going to be able to make much before my trial ran out. But when I opened Mudbox... it took me around 20 minutes to start doing exactly what I wanted. So I went with Mudbox... and I'm happy with it.

The biggest challenge for me was learning to properly Unwrap my models. It's a skill that I only recently mastered (in the last 6 months)... so for a long time I sent models from Max to Mudbox only to find myself with funky artifacts, etc. I found out the hard way that you can't depend on Render To Texture's Automatic flattening for anything complex. RTT's automatic flattening is fine for some models you need to get into Source quickly that don't need a lot of attention... but it really fails for more organic models.

I'm happy that the new Unwrap Editor in Max 2012 has been updated and optimized.