Blender Vertex Mesh export Plugin [V1.2.5].

[dustinechoes849]

Exported the riddler trophy using the same method that worked in Unreal, but in Deus Ex using the Ion Storm format.



looks kinda funky

it's supposed to look like:

unreal's screenshot feature is super broken for me lol

[Skywolf]

Try this version: https://www.dropbox.com/s/1sjrw55i65ds8 ... 2.zip?dl=0

Put the padding at the end of the vertex cooirdinates instead if before it. Which seems to be the correct method judging from what I could find.

[dustinechoes849]

Try this version: https://www.dropbox.com/s/1sjrw55i65ds8 ... 2.zip?dl=0

Put the padding at the end of the vertex cooirdinates instead if before it. Which seems to be the correct method judging from what I could find.

tried it, but with version 1.2.2 and UCC died

[Skywolf]

Seems like the same error as before. Make sure you didnt export it with Actions as animation source without having any Actions again.

[dustinechoes849]

oops, lol

switched it to scene timeline, it looks a lot more like it's supposed to, but still a bit funky
btw, I exported it with the lodmesh thing unchecked
(I bet there's some step I forgot to do)




with the lodmesh checked, it looks the same

[han]

How about:

Code: Select all

        elif FORMAT == "ION":
            for verts in me.vertices:
                co = ((corcoords(verts.co[0], 256) & 0xffff))
                r2a_out.append ((co).to_bytes(2, 'little'))
                co = ((corcoords((verts.co[1]*-1), 256) & 0xffff)) # Unreal's y axis is inverted from Blender's.
                r2a_out.append ((co).to_bytes(2, 'little'))
                co = ((corcoords(verts.co[2], 256) & 0xffff))
                r2a_out.append ((co).to_bytes(2, 'little'))
                r2a_out.append ((0).to_bytes(2, 'little'))

[Skywolf]

Looks to me like a texture problem as the holes aren't polygons missing/being displaced. It looks like it renders it as masked with the default actor dragon icon. Can you apply a different texture and see if more of the mesh appears?

If that fails try this version with Han's method applied.

[dustinechoes849]

Looks to me like a texture problem as the holes aren't polygons missing/being displaced. It looks like it renders it as masked with the default actor dragon icon. Can you apply a different texture and see if more of the mesh appears?

If that fails try this version with Han's method applied.

kinda works, though the model is super out of proportion and kinda stretched weird (too narrow).


with the version with han's method applied:

looks the same to me (I applied the green texture since it was more fitting than the red one lol)

[han]

The streching is probably caused, because another scaling needs to be used compared to Unreal, where the Z component has a bit less than the other component, while for DX each component has the same amount of bits (making it a factor of two).

[Skywolf]

The stretching is caused by this:

Code: Select all

#exec MESHMAP SCALE MESHMAP=Snek X=0.1 Y=0.1 Z=0.2

Because the Z axis is running at half the resolution as the X and Y axis does it have to be scaled to twice the size. But the ION Storm format makes every axis the same resolution. This is fixed now by making it write the .uc file like this when exporting with ION's format:

Code: Select all

#exec MESHMAP SCALE MESHMAP=Snek X=0.1 Y=0.1 Z=0.1

The ION Storm format should work correctly now.


Thank for helping me test this .

Check the first post for updated download and changelog.

[han]

It should probably use another 1/32 scaling factor in the uc file by default as there are 5 bits more for X,Y and thus making it 2^5 = 32 larger and thus you would end up at the same scaling as when using the Unreal format.

[Skywolf]

Depends on how it is implemented. If Ion Storm made it so one unit is still one unit even in their larger format then you're right. If someone would be so nice to confirm this would it be appreciated.

But since I have no way to know how Ion Storm implemented it do I rather have the model be too large than too small. The user can change this in the editor and having a too small model can make it seems like the exporter didn't export anything.

[han]

It is exactly implemented as in Unreal. The integer Vertex coordinates values get multiplied by the Scaling. Thus for dx their maximum is 32/32/16 times as large (assuming that old 3ds2unr [-128,127]^3 cube is mapped to the maximum range inside the exporter).

[Skywolf]

Fixed it. All axis now scale to 0.003125 which is 32 time smaller than it's set for Unreal's format.

[Krull0r]

Your tool works perfect!


Thank you very much, you did an awesome job skywolf.

[tzaero]

This is great, I oughta try it out for DX at some point.

[Skywolf]

Thanks for the compliments!

Time for another update though. Came across some issues during the work on my HD Dispersion Pistol model.

V1.2.6

Changelog:

Code: Select all

   1.2.6 - 
       -Fix the script comparing a str with an int when reading the Texture Slot from the Material name.
       -Made the class name now the same as the file name given during export. To avoid "Script vs. class name mismatch" errors.
       -Added a scale option to make optimizing the model easier.
       -Removed .pcx extension in the SETTEXTURE lines in the uc file. It should assign textures properly now.
       -Fixed the script using all UV Layers. Causing the UVs to be incorrect when exporting a model with more than one UV Layer. It now only uses the active one.

I can't seem to be able to edit my original post. Will have to PM Smirf about this I guess....

[han]

I can't seem to be able to edit my original post. Will have to PM Smirf about this I guess....

You probably just need to update the session, there is some button somewhere, or just logout and in again.

Another thing, sooner or later (more sooner) I want to add support to ActorX exporter and writing importer/class ingame for a vertex meshes file which would offer a higher uv precission, and compared to Unreal higher vertex precission.

Rough outlines are:
Store vertex and uv coordinates with 16 bit/component and store per mesh floating point scaling factors for each of these components.
Eventually store 3d program supplied per vertex normals, though this should probably be optional.
Not sure if the best way to go would be to just somehow cram that into the existing james mesh format or rather make the file format similiar to psa/psk files with chunks. Biggest advantage with these is certainly that these are more flexible and one could store more meta information, for example about the individual animation sequences directly inside the file instead of needing them to specificy in the import uc file.

Any interesst in adding support to your Blender exporter plugin when I move that way?

In theory Smirftsch could also easily support them in 227 without increasing package file version or adding them as a new mesh format. DWORD AndFlags, UMeshOrFlags; on UMesh are always serialized but unused. So one could set a flag there to mark changed serialization format which would be needed.

Interessting and eventually easy use case then would be a general overhaul of uv coords on stock meshes without any worries about precission. Another powerful use case would be to able to denser triangulate existing vertex animated meshes to help with surface normals, also a usage case where low tex uv hurts, and apart from dx the low vertex precission also hurts a lot.

[Skywolf]

[smiley=sad.gif]

I can't seem to be able to edit my original post. Will have to PM Smirf about this I guess....

You probably just need to update the session, there is some button somewhere, or just logout and in again.

I already asked our favorite Smurf about this. It's a forum protection meassure to prevent people from deleting their old posts rendering the topics useless.

Store vertex and uv coordinates with 16 bit/component and store per mesh floating point scaling factors for each of these components.
Eventually store 3d program supplied per vertex normals, though this should probably be optional.
Not sure if the best way to go would be to just somehow cram that into the existing james mesh format or rather make the file format similiar to psa/psk files with chunks. Biggest advantage with these is certainly that these are more flexible and one could store more meta information, for example about the individual animation sequences directly inside the file instead of needing them to specificy in the import uc file.

Seems like a good idea to me. Although I'm not entirely sure what you mean with floating point scaling factors. You mean storing the mesh scale in the mesh file instead of in the class file like it does right now?

I don't really get the advantage of storing the vertex normals. It seems to work fine without it.

Saving the animation meta data inside the files would be a good idea but should be optional or easy to edit like you can now. Blender doesn't have a proper way to make individual animation when more than one objects are involved as it stores anmation data per object. So lets say you have an Armature object and a Mesh object both will have their own Actions and Shape Key Actions. I can probably create hack and use user placed markers but this would remove flexibility and would require the user to re-export the entire animation file again just to fix a small error that would otherwise be easy to fix.

To be honest, I wouldnt mind having an animation sequence editor in UnrealED itself. So you can fix incorrect animation data without having to re-import the model again using ucc make. This would also allow for vertex meshes to be imported directly into UnrealED instead of having to use UCC (which also would be an advantage of storing the animation sequence data in the animation file).

Any interesst in adding support to your Blender exporter plugin when I move that way?

Sure. My only other concern is the file size. My ~8500 polygons (~5000 vertices) counting HD Dispersion Pistol for example has an animation file of about 3mb with only 158 animation frames. If we increase the precision (and thus the file size) this might become a problem for server owners.

Other than that, just give the the documentation and I will add support for a third format.

In theory Smirftsch could also easily support them in 227 without increasing package file version or adding them as a new mesh format. DWORD AndFlags, UMeshOrFlags; on UMesh are always serialized but unused. So one could set a flag there to mark changed serialization format which would be needed.

Interessting and eventually easy use case then would be a general overhaul of uv coords on stock meshes without any worries about precission. Another powerful use case would be to able to denser triangulate existing vertex animated meshes to help with surface normals, also a usage case where low tex uv hurts, and apart from dx the low vertex precission also hurts a lot.

How would more triangles help with surface normals? You mean giving meshes a small bezel around sharp edges?

Oh and don't get me started on the UV precision. My DPistrol model uses three textures just to get around this issue. [smiley=sad.gif] So yes, I would be down to improve this.

[han]

Seems like a good idea to me. Although I'm not entirely sure what you mean with floating point scaling factors. You mean storing the mesh scale in the mesh file instead of in the class file like it does right now?

Sort of but not quite. Basic two ideas is that you won't have to worry about fitting your mesh inside the [-128,+128]^3 cube and actually could just keep the scale as it should appear ingame. Another point of view on this is that you can select these scaling factors so get optimal precission out of your bits.

I don't really get the advantage of storing the vertex normals.

Basically calculating the vertex normal each time the mesh is rendered on the cpu is really slow, and for how the UMeshes/ULodMeshes are organized, also quite far from beeing ideal to run on a compute shader. Imho the best approach would be to have vertex normals precalculated for each frame before rendering and just blend them between animation frames like positions in the vertex shader.

Calculating them during mesh loading would take some time, so especially for a larger amount of meshes it would certainly increase loading times and for dynamically loaded meshes during the game this will most likely result in additional stuttering. Hence it certainly makes sense to include them inside the unreal package in the first place and if you already have them inside the package anyway, it just makes sense to be able to supply them directly as there are countless of schemes to calculate them and depending on the 3d suite be directly manipulated by the user (for tweaking).

Saving the animation meta data inside the files would be a good idea but should be optional or easy to edit like you can now.

I just thought of keeping the behaviour of how it works for skeletal animations. You can toggle if you read them with the IMPORTSEQS option and/or otherwise add/override them.

Sure. [...] just give the the documentation and I will add support for a third format.

Much appreciated

My only other concern is the file size. My ~8500 polygons (~5000 vertices) counting HD Dispersion Pistol for example has an animation file of about 3mb with only 158 animation frames. If we increase the precision (and thus the file size) this might become a problem for server owners.

Well, one would/should only need to serialize it in the higher precission format if it was imported out of a the high res files, so one can always just be at the point how it is now.

In general vertex animation formats are highly inefficient and i think close to 10k polygons is certainly way beyond feasable for a vertex animated mesh. Best option to go for this is certainly using skeletal animations, which are way more efficient in terms of performance, storage and bandwidth.

My intention behind this additional format is basically to allow an overhaul of existing (rather low poly) (stock content) meshes as these cannot be (easily) converted into skeletal animation based ones. So for the intended usage case the additional space requirements shouldn't be an issue.

For creating new assets, one should directly head for static and skeletal meshes. And for new content, you need vertex animated meshes just for very rare border cases.

Another implication of this intended usage case and the already high space requirements is that I just intend to support vertex normals with it, and not full tangent space required for normal maps. Most of the stock content meshes have an incredible high amount of UV cuts and also frequently reuse parts of the texture for multiple parts of the mesh. Those two things makes it not really suitable for normal mapping in the first place.

How would more triangles help with surface normals? You mean giving meshes a small bezel around sharp edges?

Yeah to help flat surfaces that way. e.g.:
[url=http://coding.hanfling.de/CratesWireframe.PNG]Wireframe[/url]
[url=http://coding.hanfling.de/CratesNormals.PNG]Normals[/url]
[url=http://coding.hanfling.de/CratesSphereMapped.PNG]Environment Mapped[/url]
[url=http://coding.hanfling.de/CratesLightOnly.PNG]Light Only[/url]
[url=http://coding.hanfling.de/CratesLightOnlyDistant.PNG]Light Only (distant)[/url]

However, you can also add more vertices to get more defined lighting on organic meshes which otherwise look [url=http://coding.hanfling.de/Soldr.PNG]quite poor[/url].

[Skywolf]

How would you go about editing meshes though? Unless it has no animations (in which case you might as well just use Static Meshes as these already support a higher precision) won't you be able to add vertices without having to redo the animations. And in that case you might as well go full skeletal.

[han]

How would you go about editing meshes though? Unless it has no animations (in which case you might as well just use Static Meshes as these already support a higher precision) won't you be able to add vertices without having to redo the animations. And in that case you might as well go full skeletal.

I have a couple of rough ideas, how to pull that off, though they most likely require some decent amount of work on tools/plugins/importer/whatever.

At least fixing up UV isn't a hard problem.

For adding more vertices/triangles there is at least one easy to solve case. For meshes where no deformation happens, but you rather have individual moving/rotating parts, one could just go ahead and modify one animation frame and based on their position relation to 'original' vertices apply the changes automated to the remaining animation frames. MedBot or RepairBot in Deus Ex would be an example where i think it would work well.

Also for these two particular meshes it might also work to just go to ahead and automated add some border if angle between faces is above a certain threshold.

Eventually a similiar approach, also taking uv space/normals/curvature into account might also work for more organic meshes.

Another hope is to be able to find some 3d authoring tool where it is possible to edit geometry on blendshapes and get the vertex animation as a blend shape in there. This would certainly be the most powerful solution.

Another idea is to put some time into experimenting with writing some tool which would be able to reconstruct (probably with user supplying hints) the original skeletal animation for the mesh. I have a few ideas for that, but in this case having it as skel mesh in the end is certainly the more suitable way to go.

[Skywolf]

Blender has blend shapes (called Shape Keys). Possibly I can write an importer that imports each frame as a seperate Shape Key which then can be turned into Keyframes so the animation can be exported again. Probably even possible to do this automatically during import.

From my tests it seems that small edits to topology (like adding bezels) would be possible without damaging the animation.

Also for these two particular meshes it might also work to just go to ahead and automated add some border if angle between faces is above a certain threshold.

Blender has a build in modifier for this. It allows bezels to be added automatically based on angle but the user can also manually tell it where to add bezels using Vertex Groups. The only problem here would be the UVs as you can't edit these without applying the modifier which Blender doesn't allow on models with Shape Keys.

Blender also has an option to do this during editing though by pressing ctrl+b after selecting edges. Which seems to work fine with Shape Keys while allowing adjustments to be made to the UVs. This would be a bit more work but seems to be the best way to go.


If you think it might be worth the time to write an importer for this I can probably do so and give it a shot atleast. Although without the more precise model format the results will likely not look great in Unreal regardless. So it might be worth waiting for this to be implemented before writing an importer that has little use outside this edge case.

[han]

On a second thought, one should probably do some experimentation with adding a second UV set for normal maps and see how well it works with creating a high res mesh for one specific animation frame, baking the normal map off it and see how well it works for other animation frames. I still have the feeling that skeletal meshes are more suitable as you can do a more resonable transforms with per vertex tangent space than with just more or less just beeing able to interpolate between the tangent space of individual animation frames. Though eventually rather low amount of polygons might be the bigger problem for this approach.

[Skywolf]

What good would normal maps do? Last time I checked Unreal didn't have support for such a thing. :-?

The importer is being worked on though.