L3DT users' community
Large 3D terrain generator

mosaic export for other file types

It doesn't hurt to ask...

mosaic export for other file types

Postby demi » Thu Dec 15, 2005 2:51 am

You know I really like this program. It is fantastic and soon I will have some screenies up.

One thing that would be nice is to export my whole map in a series of mosaics to .x format.

Right now I am importing one square (about 1/8th of the map) and then exporting it, I break the square into 8x8 grid which Blender handles. Once I have the squares split I rejoin them. One drawback is that the pixels don't line up from one file to the next and since I made the texture from the master it to does not align exactly but not really a big deal. The mesh alignment takes awhile to do though.

If I could export the entire map as a mosaic in .x I think it would solve the issues since the adjoining squares would be exactly aligned.

OH BTW - since I no longer run the decimation it saved a step.
Demi
demi
Oracle
 
Posts: 227
Joined: Thu Nov 24, 2005 4:56 am

Re: mosaic export for other file types

Postby Aaron » Thu Dec 15, 2005 8:48 am

Hi Demi,

demi wrote:You know I really like this program. It is fantastic and soon I will have some screenies up.


Aww thanks. I can't wait to see the pretty pics :D

demi wrote:One thing that would be nice is to export my whole map in a series of mosaics to .x format.


Sure, that sounds reasonable. Sometime in the new-year I'll add mosaic .x files either directly to L3DT, or to a map converter program I'm building with the SDK. The second option is my preference at the moment, as the .x writer will then be available as a plugin for other developers, as well as being used in L3DT when I rebuild big chunks of it next year (using the SDK).

demi wrote:One drawback is that the pixels don't line up from one file to the next and since I made the texture from the master it to does not align exactly but not really a big deal. The mesh alignment takes awhile to do though.


Ah, that's caused by another problem m'thinks. For two tile meshes to match up, they have to share at least one row/column of vertices, and this does not happen in L3DT at the moment. Each tile needs to be re-packed with one extra row and column of vertices from it's next neighbours. I.e. tile x0_y0 needs to have, at its right edge, an extra column containing the left-most values from tile x1_y0. Same goes for the y-direction.

L3DTVi2 gets around this problem by fetching the extra data from neighbouring tiles before the terrain is sent of for heightfield->mesh conversion and rendering. However, the water-map renderer (which is just a translucent heightfield renderer) does not yet do this trick, which explains why you can see seams in mosaic water maps (see this image).

Same goes for mosaic textures, which similarly need to be re-packed. If you look closely at mosaic textures in L3DTVi2 you’ll see subtle lines at the tile-edges. I don't have a screenshot of this from L3DTVi2 handy, but you can see the same thing in the lovely images posted recently dEaThMaStEr using TSE (look at the rock/snow interface at centre-bottom):

http://img523.imageshack.us/img523/7082/mountain10lt.jpg

Having an option to re-pack mosaics for export has been on my to-do list for a while. It's probably another thing to be added through the SDK.

demi wrote:If I could export the entire map as a mosaic in .x I think it would solve the issues since the adjoining squares would be exactly aligned.


Yes, if the tiles are re-packed too.

Cheers,
Aaron.

PS: Are any veterans of the mailing-list getting a distinct feeling of deja vu here? I'm sure we discussed this a few months back, but I can't seem to find the message. Oh, maybe it was a private communication with someone. Nope, can't find it in my mail either. Oh well, I'm losing my mind, again.
Last edited by Aaron on Wed Mar 15, 2006 11:52 am, edited 3 times in total.
User avatar
Aaron
Site Admin
 
Posts: 3689
Joined: Sun Nov 20, 2005 2:41 pm
Location: Melbourne, Australia

Postby demi » Fri Dec 16, 2005 3:07 am

I went to combine mosaics and resize. I did not know that I could split in .ter! Never mind the request. Ter files will do the job just fine.
demi
Oracle
 
Posts: 227
Joined: Thu Nov 24, 2005 4:56 am

Postby Aaron » Fri Dec 16, 2005 6:17 am

Okie dokie. Good luck.

Oh, and congratulations on your 10th post. I see you've been promoted to the rank of 'member' (from 'new member'). I was playing around with the forum's ranking system the other day, and I'm glad to see it works.

Cheers,
Aaron.
User avatar
Aaron
Site Admin
 
Posts: 3689
Joined: Sun Nov 20, 2005 2:41 pm
Location: Melbourne, Australia

Postby Q-dad » Thu Jan 19, 2006 5:46 pm

I believe I've got similar issues with the exported texture maps. My main purpose is to create tile'able terrains for the Delta Force 2 game, and that will require tile'able 1024x1024 textures and heightmaps. The Delta Force 2 engine doesn't share pixels between adjacent tiles of terrain. L3DT produces 1024x1024 textures, but with the last upper and rightmost rows of pixels rendered black or at least very dark. Thus, I can't use them for Delta Force 2, without modifying them manually. Is there an algorithm challenge in creating tile'able textures with even numbered x/y pixel counts...?

I also seem to have seen this discussion somewhere before, lol, but can't remember where, and what the conclusion was...
User avatar
Q-dad
Luminary
 
Posts: 97
Joined: Tue Nov 22, 2005 11:54 pm
Location: Jessheim, Norway

Postby demi » Thu Jan 19, 2006 10:56 pm

Q-dad wrote:I believe I've got similar issues with the exported texture maps. My main purpose is to create tile'able terrains for the Delta Force 2 game, and that will require tile'able 1024x1024 textures and heightmaps. The Delta Force 2 engine doesn't share pixels between adjacent tiles of terrain. L3DT produces 1024x1024 textures, but with the last upper and rightmost rows of pixels rendered black or at least very dark. Thus, I can't use them for Delta Force 2, without modifying them manually. Is there an algorithm challenge in creating tile'able textures with even numbered x/y pixel counts...?

I also seem to have seen this discussion somewhere before, lol, but can't remember where, and what the conclusion was...


It seems that the border around a square when exported even as a ter file still do not align correctly so the map texture will not be pixel to pixel correct. I finally split my map into 4 units as directx files and manually combined them. I then only had to do 4 units rather than 256. I then took the 4 units and subdivided tham onto 32 squares each.

I Haven't tried the new program with the bumping yet and have some real life issues to take care of so computer time is slim.

Demi
demi
Oracle
 
Posts: 227
Joined: Thu Nov 24, 2005 4:56 am

Postby Aaron » Fri Jan 20, 2006 12:23 am

Hello,

As I said above, if you're using tiled data you will need to do some re-packing to get an extra row and column of data squished into each tile. L3DTVi2 does this just before rendering, but I will add this as a special export option in L3DT too (it's now on the to-do list for release 2.4).

Cheers,
Aaron.

Edit: This topic (ie. matching-up tiled terrain & textures) is also currently being discussed on the game development algorithms list on SourceForge. The thread-view is kind of busted, but here are some of the pertinent posts:

http://sourceforge.net/mailarchive/forum.php?thread_id=9457709&forum_id=6188 (question)
http://sourceforge.net/mailarchive/message.php?msg_id=14522141 (answer)
User avatar
Aaron
Site Admin
 
Posts: 3689
Joined: Sun Nov 20, 2005 2:41 pm
Location: Melbourne, Australia


Return to Feature requests

Who is online

Users browsing this forum: No registered users and 1 guest

cron