Game Editing > Scripts & Support

[ASE] Blender 2.57 ASE Export WITH Multi-Material

<< < (2/4) > >>

MCampagnini:
ASE Exporter vMC 1.04
http://campagnini.net/2011/04/16/ase-export-for-blender-2-57/


* Multiple Materials
* Multiple UVs
* Quality of Life updates
The info and video on the site will be updated tomorrow(4/21)...too late to do it now.

kat:
Just testing export and then checking the ASE is a text editor so I've not yet opened either 'type' of output into the model viewer or UDK yet. So, multimaterial export seems to work properly relative to UDK type structure, there's a single mesh with single multmaterial (containing several sub-materials) as expected.

I'm finding that exporting the same model out composed of several sub-objects creates the expected separate "geom_objects" but not the associated individual material assignments; it looks like Blender is reading the first material it finds and assigning that as the primary and only material exported (a single material is being applied over everything).

For reference, this is how the ASE files are set up, as per the ASE export tutorial, the version on the left causes the above problem, the one on the right exports fine (which is what you'd do for multimaterialed objects [UDK]).

This is using the latest version you got uploaded as of me posting this.

PS. I'll update this once I've looked at the meshes in the model viewer.

MCampagnini:
update -

export script handles multiple uv maps and calculates out smoothing groups based on an angle set by the user during export.  future plans will add an ability to manually set smooth groups instead of automatically generating them.  The more faces you have in your mesh, the longer it will take to calculate smoothing groups.

official forum:  http://forums.epicgames.com/showthread.php?t=776986

download: http://campagnini.net/2011/04/16/ase-export-for-blender-2-57/

kat:
Thanks for the update, was wondering how things were progressing. Two points to consider;

1) not entirely sure why you've set the script up so it's calculating smoothing instead of just reading vertex split data in the file and 'format parsing' that (that's the only significant difference between Blender ASE and Max ASE where smoothing is concerned), much less costly and much quicker to do.

2) related to the above, I'm not sure why you've chosen to focus on angle based smoothing (to be set as default later?), it's practically useless for game content because it's arbitrary in implementation; the only reason people use it is because it's easier to do and more broadly, because they don't understand what smoothing is or how to properly set it up on a mesh. Both reasons result in incorrectly mesh smoothed models and encourage lazy/bad technique.

So, I'd suggest/recommend ditching the use of angle based smoothing and/or switching focus so it's an option rather than a default. I'd also find a way to parse scene data rather than have the script pull in a file and then do all the calculations (which it appears the script is doing right now?) - as an aside here, you may not know this but Goofos' very first ASE scripts for Blender did exactly what you're doing now with disastrous results, some files took tens of minutes, and very large files (terrains), hours, to output instead of seconds, it wasn't until he switched to simply parsing scene data that vast improvements were made. All you need to do is make sure the users applies any modifiers or force that on export.

Sometimes in trying to make thing easy one ends up making things more difficult  ;)

Other than the above, excellent work! ;D

[EDIT]I just read your smoothing tutorial and realised you're trying to replicate the limited mechanism that Max uses for it's smoothing systems, that's not going to work with Blender because there are two general problems with this approach.

1) as you noted in the tute, Max is limited to 32 groups so you have to be 'creative' with your application on more complex models (terrain again being a classic example) otherwise in trying to replicate Max output exactly, you're going to 'mush' (compress) groups together... that again means an arbitrary distribution based on what the script thinks is best, not the artist (the script doesn't know what the object is). If ASE is hard limited to using actual groups rather then just maintaining vertex splits (see below), then it's probably a better approach to output a warning to the user saying an object has more than the recommended groups and should be optimised better or some such... you've always got to keep control in the hands of the artist.

2) a smooth group in a game engine is ultimately nothing more than an area defined by a vertex split, so all you need to do is find a way to maintain that at output (easier sad than done I know); using Max as a reference is going to be problematic because it formats the same vertex split data as (face) 'groups', if those don't exist UDK et-al merges the very same vert splits that would otherwise be 'valid' groups were it not for their (incorrect) formatting.

MCampagnini:
Great info, thanks for the feedback.  I have been working on a second way to define smooth groups, it is just not implemented live yet.  I am aware of performance issues when dealing with complex meshes, an 11k model took about 3 minutes to push out with angle based sg's. 

I'm working on a toolbar panel inside of blender to allow you to create user defined smoothing groups a little cleaner than going through your mesh and applying the sharp seams.  For simple meshes, it is still faster to let the script calculate out the smoothing groups automatically (assuming, as you have stated, there is not a section that breaks the angle limit and requires an "artist controlled" smoothing group).

I'll go through your list when im back home in the us. I believe having a panel to control how the export will function will provide a solution to most of the current limitations you have mentioned.  Thanks again,

MC

Navigation

[0] Message Index

[#] Next page

[*] Previous page