Jump to content


Photo

Exporting models from Blender into TDM

blender lwo export

17 replies to this topic

#1 chedap

chedap

    Member

  • Member
  • PipPip
  • 64 posts

Posted 12 May 2018 - 06:39 AM

edit: TL;DR: I've tweaked the .lwo exporter to preserve autosmooth angle

 

Ahem.
When I started writing this post a couple of days ago, it was supposed to be a "please help me, models won't smooth" kind of thing, but as I started taking screenshots and such for a comprehensive view of the problem, the question morphed into a "is there a hack to get .lwo's to export the way .ase's do", then to "how to get the same surface smoothing from Blender as you can get from Lightwave" and eventually to "does anyone around know python and blender enough to fix the export plugin". But then I fixed the addon myself, so it was almost as if there's no point to the thread.

However, while googling around for a solution I stumbled upon a whole bunch of incomplete (1,2) or outright wrong (1,2) information, and whenever the question came up the issue was never really resolved completely. That might be because the problem isn't obvious, since a lot of exported models will actually end up correctly smoothed on export, leading one to believe wrong shading in rare cases is due to modeling mistakes / bad shadowmesh / etc. Point is, having the definitive .lwo smoothing post seems useful.

Identifying the problem:
 
x09xtHj.png
Here's the mesh. I add an 'edge split' modifier (I use sharp edges while modeling the low poly, so I can uncheck the 'edge angle' option).
I can now apply the modifier(s) and export to .ase (triple the mesh either in export options or in modifiers beforehand). The .ase looks alright in-game:
tpvLhs2.png
Now I'll export it to .lwo using this script. Depending on export options, here are the results:
lghk2uL.pngP0OVWbO.pngP8ftdtC.png
If I also check "remove doubles", I'll lose all of the split (sharp) edges:
AXDJdLE.png
(recalculating normals on export can be unpredictable as well, so clean up the model beforehand instead)

Right about this point I start searching for a solution online, stumble upon this and try the renderbump hack. However, all it seems to do is weld all of the vertices back together at runtime and attempt to smooth the whole surface, similarly to "remove duplicates", but with no upper threshold. (to anyone possibly reading this in the future: don't forget to revert your changes to the materials!)
ttrzlDK.png

Source of the problem:

At this point I still wasn't sure if it's even possible to get .lwo's identical to .ase's, so I installed Lightwave. Naturally, it took some time to eventually stumble upon Surface Editor (F5), and the "smoothing threshold" contained therein. But then I just had to crank it up to 180 and export to "LWO2". That fixes everything in-game:
QM6k3Fs.png

So the issue is trivial, I just have to find a way to somehow pass on a smoothing angle through the exporter. However, the "auto smooth" option on the object data tab doesn't seem to affect anything regardless of angle.
13Accqs.png

Long story short, after some hex-comparison magic, I home in on SMAN block in the exporter script:
f0R70g4.png
So what it actually does is set your smoothing angle to either 90°, 86°(??), or 0°, depending on whether you've chosen "idtech compatible", "smoothed", or neither.

The solution:

Now, I don't know Python and I don't know Blender scripting, so I can't say with full certainty that I didn't break anything. But I did cobble together a version of the script that seems to do the job. Here it is, mirror / do whatever you want with it.

If your mesh has autosmooth enabled, and you've checked "idtech" or "smoothed" on export, your chosen autosmooth angle will now transfer to the surface in .lwo:
Cfjtaun.png
I took the liberty of changing the default export options to what seems to suit TDM the best, you can just open the script in notepad and edit them to your taste.

Wrapping up, there are still some mysteries I didn't solve, such as "idtech compatible" models taking up only half the size of models exported otherwise (including from Lightwave itself), there doesn't seem to be any visible difference in-game, at least in TDM. That "1.5 radian" in the code still makes me scratch my head. And I still don't know if the 4-8x size savings over .ase matter for in-game memory at all (but at least I know I won't have to edit the *BITMAPs manually anymore). Even after all this, the .ase still has just slightly better shading, but since the outputs of the exporter and Lightwave itself are now identical, seems safe to say it's as good as it gets.


Edited by chedap, 12 May 2018 - 09:25 AM.

  • HMart and RPGista like this

#2 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1194 posts

Posted 12 May 2018 - 07:33 AM

Is this model properly unwrapped? It looks so. IMO the best solution would be to use one smoothing group for the final model, and using UV islands to define where you want to have hard edges, along with different smoothing groups but only for baking normals. This way you both save up on vertices (not sure why model DR model viewer also says I have less triangles) and benefit from better shading. In general I try to use as few smoothing groups as I can, so normalmaps can do their work.


Edited by Judith, 12 May 2018 - 07:55 AM.


#3 chedap

chedap

    Member

  • Member
  • PipPip
  • 64 posts

Posted 12 May 2018 - 09:16 AM

Is this model properly unwrapped?

I mean, it's not some masterpiece of packing and alignment or anything, but it does its job:

Yrb4wDU.jpgcdgDE4B.jpg

(on the right: same mesh (via .fbx) and textures (legacy specular shader) dropped into unity)

 

If I unwrapped the whole thing like you say, without any splits, the normal map would have to compensate for the entire mesh.

RWywSQS.jpgxgjQjIa.jpg

 

In theory, the engine then applies the normal map on a fully smoothed mesh and flat surfaces go back to being flat, but in practice it can't quite hit the mark:

2upoBpf.png

Note how the flat surface now has some waviness. Didn't get the screenshot, but the holes look bad as well. Maybe I did some mistake along the way, but I think I understand the process enough to at least avoid the obvious ones.

Also, I don't know how/if TDM creates mipmaps for .tga normalmaps, but there is another known problem with entire meshes using averaged normals: when compressed, the skewing will get exaggerated, so even with a perfect rendering process there are pitfalls.


Edited by chedap, 12 May 2018 - 09:18 AM.


#4 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1194 posts

Posted 12 May 2018 - 10:29 AM

Yeah, the first setup isn't perfect, but doesn't waste the texture space as much as the second one. Besides, it doesn't match SGs you set up on the model in the first post, if I see correctly? Btw. you can use uv mirroring for the same parts that aren't in view simultaneously. Anyway I'd go back to the first setup and use SGs on the low res model to define hard egdes for baking normals, that should have some effect too. Averaged normals is a problem regardless of engine, AFAIK. In 3dsmax I switch between using cage and averaged normals to see what looks best.


Edited by Judith, 12 May 2018 - 10:32 AM.


#5 chedap

chedap

    Member

  • Member
  • PipPip
  • 64 posts

Posted 12 May 2018 - 11:29 AM

Apart from one extra uv seam along the horn, sharp edges match uv islands exactly. By SGs you mean max smoothgroups, right? Unless you bake with explicit normals, smoothgoups/hard edges don't affect baking, and it's a bad idea to bake with explicit normals anyway - in case of distortions it's always better to just subdivide the low-poly mesh (without smoothing) a bunch of times before baking. In max, you'd select the faces and press "tesselate" iirc. Try it, you probably won't tinker with the cage ever again.



#6 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1194 posts

Posted 12 May 2018 - 01:35 PM

Yup, I use SGs for short :) If I'm not mistaken, you have hard edge on that round part of the base of the anvil in the first post, while UVs have that base stitched to the rest of the model (in the second set of UVs).

 

In 3dsmax cage still has important uses, i.e. when hi-res mesh intersects the surface of your low-res mesh, averaged normals will often will give you errors. It's also useful for stuf like floaters, as averaged normals tend to skew them quite noticeably. I use low-res mesh subdivisions mostly when I encounter wavines, typical example being low-res cyliders.

 

In general I follow guidelines found here: https://www.dropbox.... Games.pdf?dl=1


Edited by Judith, 12 May 2018 - 01:36 PM.


#7 Arcturus

Arcturus

    Advanced Member

  • Development Role
  • PipPipPip
  • 1615 posts

Posted 12 May 2018 - 09:03 PM

Did anyone manage to get custom normals working in TDM?


It's only a model... /// My channel on YouTube /// CGtrader , Turbosquid


#8 RPGista

RPGista

    Advanced Member

  • Member
  • PipPipPip
  • 1488 posts

Posted 12 May 2018 - 11:12 PM

Hey, thats pretty sweet, man. Thanks! Will definitely be trying it out. I was aware of the LWO smoothing issues and is great to know this has been worked on. 



#9 chedap

chedap

    Member

  • Member
  • PipPip
  • 64 posts

Posted 13 May 2018 - 12:47 AM

Figured I'd post a useful batch script as well. This one is unrelated to Blender, but I don't know where to post it instead.

It creates a generic material definition based on the name of a file you've selected, then moves the related textures from your current location to your FM folder.
Download the .bat and put it anywhere on your PC. Type "shell:sendto" in the explorer address bar. Put a shortcut to the batch file you've downloaded here. Now you can right-click any file, "send" it to the script, and if all goes well, your material is immediately ready to use.

Caveats: made it for personal use, and the whole point is to save time, so it won't ask anything, you should change path vars beforehand (just right click > edit). It won't give warnings about overwriting an existing .mtr. It handles spaces in filenames and paths, but you probably should avoid them anyway. It will automatically add normal/specular stages if it finds _local.tga or _s.tga in the same folder.

Working with just .tga's is (imo) easier while working, but you should convert them before shipping the FM. If you prefer to work with .dds/.jpg right away, you should edit that into the script. And don't forget to eventually change the surface type (wood by default).

 

In general I follow guidelines found here

Well, that guide mentions same kind of non-deforming tesselation I meant. It is especially useful when dealing with skewed floaters.

Did anyone manage to get custom normals working in TDM?

Per-vertex? I don't think they show up in TDM, but they do get exported to .lwo as a "vertex normal map".



#10 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1194 posts

Posted 13 May 2018 - 04:24 AM

Did anyone manage to get custom normals working in TDM?

 

I tried changing model normals with EditNormals stack in max, TDM doesn't seem to recognize them. But I guess could bake that and add it to a normalmap.



#11 Arcturus

Arcturus

    Advanced Member

  • Development Role
  • PipPipPip
  • 1615 posts

Posted 13 May 2018 - 04:25 AM

Per-vertex? I don't think they show up in TDM, but they do get exported to .lwo as a "vertex normal map".

Like this:

 

 

It's explained well here.


It's only a model... /// My channel on YouTube /// CGtrader , Turbosquid


#12 R Soul

R Soul

    Member

  • Member
  • PipPip
  • 91 posts

Posted 13 May 2018 - 10:28 AM

I don't quite follow what's being said here, but when I want a face to have sharp edges, I select it and press Y to separate its vertices (which could be thought of as the opposite of remove doubles). When exporting the .lwo, I have the 'smoothed' box is checked, and 'remove doubles' and 'recalculate normals' are unchecked.


Edited by R Soul, 17 May 2018 - 05:18 PM.


#13 chedap

chedap

    Member

  • Member
  • PipPip
  • 64 posts

Posted 13 May 2018 - 02:08 PM

Yes, you're effectively splitting the edges around. Before I tweaked the exporter, checking "smoothed" on export would result in 86° smoothing threshold on the rest of the surface (parts you haven't split). Which is fine for a lot of cases, but in edge cases like with the anvil, thats not enough: you'd want 180°, otherwise there will be unintended sharp edges.

It's not just for edge cases though. Before, you had to split the edges manually, otherwise your only choice of autosmooth was 86° or 0° with nothing in-between. However, since the custom exporter will now respect your autosmooth angle, it's more wysiwyg: for simpler objects it might be enough to just set an appropriate angle inside Blender, with no manual splits needed.

 

edit: I realized I assume some not-too-obvious blender knowledge on the part of the reader, so here's a quick rundown on smooth shading. Once you switch from default flat (faceted) shading, it'll attempt to smooth the whole mesh regardless of angles and hard edges. To make use of those you'll have to turn on autosmooth. Now you can mark edges as sharp (ctrl+e) and they will display as such in blender. However, they will not transfer to TDM, so you'd need to split these hard edges before export ('edge split' modifier).


Edited by chedap, 13 May 2018 - 02:46 PM.


#14 R Soul

R Soul

    Member

  • Member
  • PipPip
  • 91 posts

Posted 17 May 2018 - 05:26 PM

Thanks for the explanation. I think I'll make use of the autosmooth value now; it's better than having lots of manually split edges.



#15 Spooks

Spooks

    Member

  • Member
  • PipPip
  • 446 posts

Posted 20 May 2018 - 12:27 PM

 Even after all this, the .ase still has just slightly better shading, but since the outputs of the exporter and Lightwave itself are now identical, seems safe to say it's as good as it gets.

 

Hello, thank you for this updated script. On this point, in particular, is this what you mean?

 

Spoiler

 

Right side is the .lwo, left is the .ase. I've overridden the materials to something more consistent than default textures for this model. It must be something to do with the edge or face normals, but I'm not knowledgeable enough to guess. It's a little irksome, but it's near invisible with real, detailed textures.


My FMs: The King of Diamonds (2016)

 

Visit my Mapbook thread sometimes!


#16 chedap

chedap

    Member

  • Member
  • PipPip
  • 64 posts

Posted 20 May 2018 - 04:25 PM

Without seeing the geometry that's a bit too non-specific to get anything out of.

What I meant is that if you open both images (1, 2) and switch between them, you'll notice that a thin triangle at the horn's base gets smoothed slightly better in .ase. It's a fairly extreme case though.



#17 Spooks

Spooks

    Member

  • Member
  • PipPip
  • 446 posts

Posted 21 May 2018 - 07:11 AM

Well I've run into a snag and need to report it. chedap, I know you just fixed up the existing script, but this is related to smoothnig, so perhaps you, or someone else who works with Blender can offer any ideas on what's causing this.

 

444.jpg

 

This is what's happening to one of my models after exporting. Two are tiled together, and you can clearly see that the smoothing is going along the triangles' edges instead of being constant. (it looks the same in-game, but this is a screenshot Springheel took in Lightwave). In Blender, the problematic part looks just fine:

 

unknown.png

 

 

I tried all combinations of export options, recalculating the normals (of course), even made a custom plane inside Blender (since this is a .lwo import) and that exported with the same problem, too. So, it's got to be something with the exporter... .ase, in the meantime, has even normals.


My FMs: The King of Diamonds (2016)

 

Visit my Mapbook thread sometimes!


#18 chedap

chedap

    Member

  • Member
  • PipPip
  • 64 posts

Posted 21 May 2018 - 11:09 AM

Tried replicating: a/b, three spans are separate models. There's a bit of a step in shading at the bottom-right junction, and it isn't there with .ase (a/b). Seems to be related to triangulation, and is only visible under certain lighting. But it's definitely not nearly as severe as in your case. Your example isn't capped at both ends or anything, right? Can you post the mesh? Feel free to PM.





Reply to this topic



  



Also tagged with one or more of these keywords: blender, lwo, export

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users