hello again,

since this post has a variety of stuff (about terrain) I didn't know what sub-forum to put it in.

I just tried the new heightmap importer and I must say it's awesome, certainly more than I expected (the add and remove are a nice addition). Getting just the desired scale is a bit tricky but it can be made to work.
anyway I imported my heightmap, but I must say my game world is huge (then again this engine is meant for unlimited sized worlds). Importing the whole thing and then building it took some long minutes but I can deal with that. Now here come my comments about it.

First topic: Disk space size
my .world/Game/Area folder has almost 40,000 files, spanning 2.05 GB in space. I don't even want to think how big it will be once I've placed grass, trees, plants, items, etc; but for an indy game 2 GB in terrain is way too much.
In our old engine our terrain was made up of static meshes with 1 LOD level (and as Esenthel, we also had LOD terrain chunks have the same polygons on the edges as normal ones, so that they were seamless), and while it didn't look as good or have all that much features, my terrain for the same world size was only 67 MB (LOD meshes included).
Now there's 2 things I can easily point out that are different from both terrains:
1. My terrain had less polygons per the same square area. Yes Esenthel's look better but mine looked fine. I'd like to be able to adjust the terrain polygon density to my game's needs.
2. My terrain's chunks were bigger. This makes it so overall there's less terrain chunks, meaning there's less seams between terrains, meaning there's less of those LOD-adjusting polygons (those that make the terrain seamless between normal and LOD terrains).
now if we had some more freedom in these 2 aspects I'm sure we could work the terrain into our needs.

Second topic: Performance and view distance
This is more of a result from the first one. In our old engine the view distance was huge, and we certainly would like to have it that way.
In the Esenthel engine if I widen the view distance (pressing [ and ] in-game), the game starts to be choppy at even less than half of what I had in the old engine. Of course this is because I had less polygons on my terrain, but it was also because I could manually adjust the distance at which the low-res (LOD) terrain would become visible instead of the normal one.
If I could make more of my already visible terrain use less polygons I'd get better performance, and so I'd be able to adjust for more viewing distance.

Third topic: Interiors
I say a post where someone asked a bunch of stuff, including if the engine had portals, the answer was no but there wasn't any extra info.
My question here is, if someone has a game with a great portion of interiors (like mine), or just wants to do an all-interior game, what's the way to handle them right now, or what are the plans for this?

later

bump

can we get an answer plz? it's actually quite important for us to try handle this
thanks

yes of course, sorry im just not in my town until the end of the week.

Quote:First topic: Disk space size

have you tried selecting "menu\heightmap\low quality" before building? it should generate the mesh and phys terrain 4x smaller. dont worry about grass/objects coz they use much less memory than the terrain.

Quote:Third topic: Interiors

1st approach - just include the interiors as object with "embed to terrain" option and then rely on implemented "earlyZ and deferred rendering" in the engine

2nd approach - handle rendering interiors manually with custom classess for portals or another occlusion culling.

Chosker Wrote:First topic: Disk space size

Achieving drastically reduces the file size, don't entrust .pak files for compression since they aren't really designed for compressing, for example if I compress the engine.pak file from Data which is over 70mb using winrar , once compressed it only takes 1.7mb, so you see compressing really helps

As for the terrains ( worlds ), the only thing it does is reference the model from the
Data folder, so it doesn't really import it into a special file, it just sets " Data/This/Model/From/This/Path.mesh goes here with this rotation etc.."

oh, thanks both for your replies

Quote:have you tried selecting "menu\heightmap\low quality" before building? it should generate the mesh and phys terrain 4x smaller. dont worry about grass/objects coz they use much less memory than the terrain.

yes. I just tried it again. same filesize. would that make high-quality 8 GB?

Quote:Third topic: Interiors

ok thanks for that I'll talk to my programmer about that.

Quote:Achieving drastically reduces the file size, don't entrust .pak files for compression since they aren't really designed for compressing, for example if I compress the engine.pak file from Data which is over 70mb using winrar , once compressed it only takes 1.7mb, so you see compressing really helps

I'm sorry I think I didn't understand you fully. If what you're suggesting is that I compress my world folder, then I still get 945mb (winrar, maximum compression). For distribution, that could in theory work when the game is finished, but the problem is I can't really be distributing a single 945mb rar file over and over through svn with my programmer, small split terrain/world sectors make so much more sense.

Quote:As for the terrains ( worlds ), the only thing it does is reference the model from the
Data folder, so it doesn't really import it into a special file, it just sets " Data/This/Model/From/This/Path.mesh goes here with this rotation etc.."

Again I didn't understand you fully, but here I guess you're referring to objects placed in the world, not the terrain meshes themselves (which don't seem to exist as .mesh files).
I'm only really concerned about terrain here

Quote:but the problem is I can't really be distributing a single 945mb rar file over and over through svn with my programmer, small split terrain/world sectors make so much more sense.

please use the engine's "version control server" it allows you to send the world between multiple computers.

important - only those areas are sent which were changed.


would you like to have an option to even further decrease the terrain mesh resolution? (like "heightmap\low quality" x2 ? )

Quote:please use the engine's "version control server" it allows you to send the world between multiple computers.

important - only those areas are sent which were changed.

We apreciate the version control server, we intend to use it in the near future.
The thing is more about bandwidth, and the first time is still a 2 GB transfer. plus when we release the game to public, people will be hesitant to download such a big file for an indy game :?

Quote:would you like to have an option to even further decrease the terrain mesh resolution? (like "heightmap\low quality" x2 ? )

If by decreasing by x2 could reduce the diskpace by 1/2 then it would be better. But thinking again, it's 1/2 on a square so in theory it'd actually be 1/4th of the disk space. Still I don't think 500mb is small enough for us.
My old engine's terrain had (nearly exactly) 1 vertex for every 5 vertexes in an Esenthel terrain, which means that visually we should be fine with 1/4 of the current terrain mesh resolution. If my theory and my math are right that'd be about 125mb, which would be a pretty number
so yes! we'd apreciate such an option, but probably only decrease up to x4 would be good for us


Btw the topic about adjusting the distance at which the low-res (LOD) terrain becomes visible instead of the normal one, is still a question for us. Is there some sort of way to do this?

thanks!

Quote:I'm sorry I think I didn't understand you fully. If what you're suggesting is that I compress my world folder, then I still get 945mb (winrar, maximum compression). For distribution, that could in theory work when the game is finished, but the problem is I can't really be distributing a single 945mb rar file over and over through svn with my programmer, small split terrain/world sectors make so much more sense.

Yeah I was actually talking about compressing it before distributing the game, as for the map I thought that you already knew about the CVS-like feature and even if you didn't, you could've always used shared/network folder which automatically updates when a file is modified,added or deleted

Quote:Again I didn't understand you fully, but here I guess you're referring to objects placed in the world, not the terrain meshes themselves (which don't seem to exist as .mesh files).
I'm only really concerned about terrain here

I must've misunderstood your post

Quote:would you like to have an option to even further decrease the terrain mesh resolution? (like "heightmap\low quality" x2 ? )

That would be a great feature, LOD terrain would be even better

Ok we have no longer need for this. instead of needing all that complicated stuff we'll just be scaling our objects so everything is smaller, therefore compared to our objects, the terrain polygons will now be larger, and we'll use less terrain chunks
Still thanks for your support!

And now that I'm messing with the materials I'm seeing there's certainly more small features we'll need. It's related to shaders, so first I'll ask the following.
When we buy the indy license (the cheap one ), I understand we're allowed to modify the shaders. If for example I add a new texture in an object (ie. imagine I want a detail texture but as a normalmap), how would that be reflected in the material editor? (since there's a limited amount of parameter sliders, and of texture slots)

material editor will remain the same.
you will be able to replace the shaders with your custom ones, there you can use the textures any way you want.