Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[monks]

I've just dug out the terrain again from storage and I'm getting things ready for the next terrain release. The problem of the terrain being generally way too high will be fixed. Fixing this means that we'l be able to approach the biome and texture creation using more or less real world figures for how/where to place stuff.
 The next release the terrain will be much more ready to take 3D models.
Having used Unity for a short while I think it would be the ideal choice to refine the terrain at the site locations. It would also be great for creating quick mock ups of the places. It's free as well. World Machine is great for a lot of things but it has no paint tools.
 There's just one problem and that's Unity only supports the .raw terrain format. Our main project data is in hfz format. I've tried the workflow between World Machine and Unity using.raw and there's a slight discrepancy between how they both read/write (not sure which) the elevation values in the file. I don't think there's an easy way to resolve that. So we need another format.  Unity doesn't support anythin else but .raw but I use a 3rd party plugin for Unity called Terrain Composer. I've asked the dev if it would be possible to implement hfz suport. If he does, that would mean that if you also wanted to model some terrain for the sites you'd have to buy a copy of Terrain Composer to use the same workflow as me. There's always the option of people using other workflows between say Crytek or Unreal. All the terrain would be imported back into the main World Machine project so it would have to be tested to make sure there were no discrepancies between how elevation is read/written.
 The other option is for folks to use a 3D package like Blender or Max. World Machine does have obj support. The downside of that is, you don't really have the terrain/veg paint functionality that Unity has nor the procedural vegetation/object placement that Terrain Composer does.
 The discrepancy isn't a big deal necessarily IF we avoided copying over data from the tile edges. We could do that with a combine mask in WM easily enough. Where it really matters though is if you start creating meshes such as river surfaces. Any differences in the terrain at any point will undo all your hard work.

monks

[PytonPago]

 ... the Blender way would be nice ... OT can flatten the terrain under a building, but this way a sub-terrain level design could work better whiteout the terrain getting into the model room-space. Also, there may be a lot of detail redone during construction of cities.  --- would there be a way to get .obj format of certain tiles in all lower LODs ?  Also, OT has a square edges height data terrain, so when you edit and put it in again, will you stick at the same square density of height data, or is a higher density allowed there ? (like, all the planes in 10m square and urban area tiles whyte around 2-0,5m square to have the needed detail there).  - as for dirt roads and rivers, i think there will be a more complex option set for those in future. May be good hawing a talk about these things whyte Cameni (whyte all possible near water surface/material possibilities in mind). A possible waterfall-generator in the river tool, if the slope of the vector track terrain gets over 90 degree angle would be interesting too.

[monks]

Good point about the terrain LODs if we're using obj for site terrains.
 will it be important for the LODs to match exactly? If they don't will it produce bad visible artifacts/popping? I think it would be closer up.
 I think we should use a combination of terrain patches (written into our World Machine project and then exported and rewritten in a ME-DEM terrain update), and obj patches for areas WITHIN that area.
 
I think recreating the broad features of the terrain to generally fit the large scale features for the area in a terrain height format at full res in say Unity, a terrain modelling program or a 3D package. (larger areas will be difficult in a 3D package though but it is possible to export render areas smaller than tile sizes from World Machine). Then for details which require meshes, such as terrain overhangs, etc, use an obj mesh. I think the trick is to make sure that any terrain mesh .obj never includes the tile edge itself. It it did we'd have more LOD issues to deal with. Or would we? Would we need more than one terrain LOD, surely yes, and they'd have to match OT's LOD...I think. You probably have a better understanding of the details here Pyton.

 So with this division, Outerra engine will effectively handle the LODs for the terrain in the ME-DEM terrain update. Without further development by the devs I can't think of any other way to approach it.


So for terrain changes at larger scale workflow will be:

WM core data -> app to alter specific site terrain -> WM core data -> ME-DEM terrain update
 With the constraint that alterations must preserve exactly agreement of elevations across tile boundaries.

For small scale (sub pixel mesh .obj)
WM core data -> app to alter specific site terrain -> Outerra as .otx
 We will need to understand the issues with LOD management in Outerra. Care will have to be taken with matching/blending textures as well.

Rivers is a whole big subject. I don't think the devs are ready for that yet.

 That's the way I'm seeing this so far.... Other questions will have to be answered by the devs.

monks

[PytonPago]

Good point about the terrain LODs if we're using obj for site terrains.
 will it be important for the LODs to match exactly? If they don't will it produce bad visible artifacts/popping? I think it would be closer up.
 I think we should use a combination of terrain patches (written into our World Machine project and then exported and rewritten in a ME-DEM terrain update), and obj patches for areas WITHIN that area.

I dont see a problem to the squares - just thought it would be handled by OT more simple if its the orginal tile size and placements (affected original OT tiles that is) - for modeling, you dont mind that a bigger area is in model. There is a good overlook of the surrounding area too this way. Also, you just modify the internal tile area, whyle the edges of the whole plain you modify stays in the orginal state - so there should not be problems whyte overlapping.

Yet just find a slick way to export all LODs (or all lower from ones needed - we certainly do not need to modify those at 100+ km distance visibility for a village) tiles into an .obj (or something, that can be converted to 3D modeling software types) and importing modified versions back. Maybe ... well have to ask Cameni, if he could script a smart "Terrain exporter" as part of the dev-package for 3D modeling purposes and as a detail-terrain tool. I think it could proof a handy tool for the engine itself.

As for rivers - it shouldnt be much problem to discuss it - they surely have some ideas for it already - they just get some surplus of ideas, whyle hawing their own time schedule stuff working, getting into it, when they are ready and determined to.

 -- we should organize some live discussion sessions white them - Larry King style

[monks]

I think that woman just told Larry his gfx card cannot run Outerra...

 Outerra obviously needs some development for this kind of stuff we're doing- with locations and objects but I can think of a ton of other things more important- biomes and clouds. There will be some improvements with the biomes interface which will help us out and it all needs coding. For eg, I think we need more control over the snow placement latitude.
 We've got a lot of improvements to make on the textures/biomes for M-E. The goal is get it looking very close to Earth.
 Yes, rivers will be a big addition and things will really start to come to life when they arrive, but first I think water bodies with multiple heights, lakes will arrive.
 For me the two features I'm most looking forward to are rivers and underground areas. I was thinking a lot about rivers in the last few days and I was considering using other external programs to create them but I returned to my original conclusion that the only way to create them is in the renderer itself. They are sub pixel details and need vector tools- OT especially needs vector. I have a tool in Unity called EasyRoads. That's a very nice tool to use but it would not be good in Outerra- it has no vector import (it doesn't need any because Unity editor is still 32 bit and so terrain sizes are never larger than 8096). For us, it would be extremely useful to be able to import rivers as .shp. I think at some point Cameni is planning to support .shp and he will get huge benefits because the engine could import a vast array of GIS data out there. He'll have to import the river data for Earth in some format. we could export our vectors in other formats too, but I think .shp is the most widely used. I guess it depends somewhat on what Cameni's data sources will be.

monks

[PytonPago]

Yes ... seems waiting is on schedule again. ... in the mean time, i just stick to modelling and newbie support.