Correspondence concerning plugins and scripts; development, use, bugs and ideas.
YUMMM, that sounds/looks promising! Aaron, thanks a lot for your great commitment to that case! (ah, and, sorry for the late reply).
Concerning the terrain normals: Well, I use the "TN" map to slice and export into the mesh as normal map.
TBH, the only reason for this is that I didn't even know about "TN-tangent", hahaha. Must see what that is...
>>...I apologise for any inconvenience caused by this delay...
You don't need to, really. My exporter is a hobby project, and should not cause any "stress factors" on either side.
Actually, I was already afraid of being maybe a bit "too tossy" about all the changes...
I've made some more progress with the tiled mesh exporter, a video of which you can see here. The decimator now generates seamlessly tiled sets of mesh files OK, and a new exporter tool saves the material file and texture map tile for each mesh file. I still have a few further tweaks to finish on the mesh decimator and tiled exporter, but the bulk of the hard work is now complete. Update soon [so I keep saying...]
Wonderful work, Aaron (and thanks for the "hat tip", heh ).
Meanwhile, I learned a bit more about that "tangent space" and "object space" normal maps. Not sure still *what* type my exporter would finally need to use, though.
I have asked over at the DXStudio forums what their engine expects - answer pending. FYI
Ah, just got the feedback that "tangent space" would be it.
So, I'm going to use TN-tangent, I think (as this is Pro version only, the export will be without normal map for Std then; only fair).
I've finally got something ready to share. You will find on the downloads page L3DT Pro v2.9 build 22, which includes support for seamlessly tiled mesh exports for the OBJ and 3DS formats, and also includes the required API functions to allow plugins to generated seamlessly tiled mesh objects.
The menu option for the new exporter is 'File->Export optimised mesh', and the user guide is on-line here. This option replaces the old 'File->Export->Export OBJ and MTL' and 'File->Export->Export 3DS and texture' menu items, which have been removed.
For the purposes of your plugin, the updated plugin API (v2.9.8) includes helper functions for calling the mesh decimator, which are declared in the <helper/atMeshDecimator.h> file. For tiled maps, be sure to set the flags parameter to MESHDEC_FULLRES_EDGES, as this will ensure the edge triangles are unoptimised. You'll probably also want to set the MESHDEC_NORMALS and MESHDEC_TEXCOORDS flags too, as these will provide automatically-generated vertex normals and texture coordinates.
In the coming weeks I plan to extend the exporter to support the other mesh formats otherwise supported by L3DT (namely X, B3D and TIN files.) If you like, we could also integrate your exporter with this new mesh exporter UI, as this would allow you to take advantage of the built-in support for exporting selected areas, auxiliary maps, and alternative coordinate systems. To do this, your plugin would need to define an extension function for saving a CzMesh object, and I would need to add the DXMESH option to the exporter and add some trivial plumbing code. If you're interested, please let me know, and I'll send you over an example of the required extension function (taken from the 3DS plugin, which does the same thing).
As always, please let me know if you find any problems or would like to suggest any changes.
Simply georgeous! Nothing really more to say.
I'll be playing with all that new features over the coming days. Also, having a good thought about the exporter integration (thanks for offering).
Uhm, say, any chance to have a Std dev build 22 one day, too? I might be overdoing things, but would really like to check with both versions finally...
(yah yah, I know, "no matter how much you give them, they always come up with more" )
Just posting some quick pictures from test runs. No problems encountered so far
Aaron, you surely know how to do programming, hats off! Stay tuned...
Okay, finally I have set up the first version of my "new" exporter for download (link see below). The package includes some documentation, too
Actually, aligning the textures of tiled terrains (so no seams would be notable) gave me some headaches. This partly works now, but is still not satisfying (DXStudio doesn't seem to like non-2^n sized textures, which makes things a bit more complicated, too). That problem has nothing to do with any of the new L3DT features, though. There, all worked out of the box. The only thing I noticed with the current development build is - when a project is loading (one texture after the other), and the user clicks on "File.." while still loading, it crashed.
In case of testing the plugin, please remember when clicking on the exported "viewer helper" (which is a DXStudio document), the DXStudio player needs to be installed. It would not run otherwise. The player can be obtained here: http://www.dxstudio.com/download2.aspx
Also, I had a good thought about integrating the DXMesh exporter into the "official" exporter plugins' list. The new "Export optimised mesh" pipeline is perfectly set up, I see! Well thought, straight forward, etc. Well, simply "Aaron-quality".
In respect to 'my' exporter, I see some obstacles, though. Actually, I like the "freedom" of an own dialog window with total control of all available options. This would give me the possibility to implement additional (and very special) features like DXStudio water mesh system, DXStudio 'physics mesh' creation and whatnot else. Being "bound" to the standards of a "regular" exporter could be a constraint then. Also, updating the plugin for bug fixes or new features would be a bit more complicated(?), I reckon.
Having said this, I feel that an integration into the "standards exporter" is only 2nd best choice here. As said, thank you very much for that offer. Highly appreciated, but I would rather not do so.
I'm now going to review (hopefully incoming) test reports from DXStudio users. Also, need to deal with the texture alignment at seams a bit more. And then, there is those "special features", too, hehe.
Again, Aaron, thanks a lot for your help and commitment. If there is anything I can do to support v3 development, just tell me.
Reference (DXStudio Forum): http://www.dxstudio.com/forumtopic.aspx ... 0fad663aae
Plugin Download Page: http://www.mikoweb.eu/index.php?node=41
I've uploaded build 23, which has some further optimisations in the mesh renderer that improves the decimation speed, particularly for large maps. I've also added progress bars to all the decimation steps, and fixed some issues with progress bar responsiveness.
You mentioned a water mesh exporter; this is on my dev plan for the mesh decimator too. However, to ensure that there are no gaps between the water and terrain meshes at the edges, the decimator will need to be heavily modified to force high-res triangles at the water's edge for both the terrain and the water meshes. That's no small feat, so it's going to take a bit more time (i.e. it may not be included in L3DT v3.0).
Fair enough; on second thought, I'd probably make the same call too.
Thanks for the bug report. I've not been able to reproduce this, but I'll look into it further. Please let me know if you can reproduce it in build 23, as it may be related to the poor progress bar message handling that I've now fixed (unlikely, but possible).
ah, I see we are on dev build 24 already. Tried to reproduce my "crash problem" with that, but couldn't.
It might well have been an issue that was caused by my ongoing plugin testing (including irregular program aborts etc).
As for water meshes: Yeah, I see the problem. Although... I would not completely agree that *both* meshes (water plane and terrain mesh) need to be hi-res faced at connection edges. I mean, lets assume we're treating the water plane as an own object with own vertices *and* do know the boundary edges given by the terrain faces (i.e. intersection lines of water height level with terrain triangles). Then, couldn't the water plane be hi-res faced at the edges (to adapt to the terrain shape), but the terrain itself would not need to be (i.e. remain as after decimation)? Not sure if my thinking covers all possibilities here, though.
Actually, when making tests with a water surface creator tool for DXStudio, I chose a "far more lazy" approach:
Check for existing terrain slopes by ray casting, then just move the water surface's border vertices "a bit more in" (reference: http://www.youtube.com/watch?v=bUlQjfOt3Uo ). Admittedly, this might not always work as intended.
Now, I'm thinking about taking the existing L3DT WaterMap as a base ("where is water, where is not"), then rise an external app that would re-use the said ray casting and positioning and push out some water surface meshes. Might be good for a starter, but is still in "brain storming phase" Just FYI.
That basically how I made water surfaces in Maya for my recent terrain, and I had water at different levels.. Export water surface png, use it as a texture on a plane, and cut the plane into polys just "outside" of all the water surfaces. Worked pretty good once I got it into the UDK and manually positioned the height of the objects.. but it not a good solution for more than a handful of objects.
Who is online
Users browsing this forum: No registered users and 2 guests