VeTaL

Well, if i'd use smaller one: 1024 * 1024 * 2 = 2 mb 1024 * 1024 * 4 = 4 mb 1024 * 1024 * 4 = 4 mb total it would be only 10 mbs. Now, i'll write editor that would connect terrains by 9, so it would be 90 mbs for large terrain 3000*3000. Now, i can load 2 of them and it would take 180 mbs, wich is not too many as you use 165. If this would be too much, i can make "parts" smaller to 512 and they would eat 0.5 + 1 + 1 = 2.5 mb. About physics: i dont know if Julio added fucntions for terrain so i can remove from terrains physic some parts, so looking like i need to reload all new terrain. What about , i think freezing of physic would help: i freeze all physic for a while, load new terrain and unfreeze it again(but looking like a little lag would take a place). About float precision: well, looking like this may be a large system, that would move all objects to new places, so the center of world would be moved to new place. About vegetation: i didnt look deeper in it, so i can say nothing about it for now. About tons of poly: i'm thinking about loading second terrain in another thread and then just copy it instead of first one.

Then there would be some problems with physics and trees... But are there any variants, how to solve trouble with copying?

Well... looking like the only solution is to write a terrain loader, that would hold parts of terrain, generate new terrain from 9 parts, load them to memory in the second thread and then just copy it instead of the old one. What do you thinking about it?

Great

So, you want to say, that there is no way of loading dynamic terrain? Reseting of the world origin looking like not a huge problem. //Please correct me if I'm wrong, I'd love to be able to do what you'd like to do. Sometimes you have to scale back our wants and work with what you can do. Sometimes less is more and it works out better. You're absolutely right, but as we are making RPG game, there is no sense to make in 2010 year a game without dynamic level loading.

mikraj, There are great trees in Leadwerks, just try them

http://leadwerks.com/werkspace/index.php?/topic/1513-leadwerks-30/page__view__findpost__p__15546 There are some people, who want to see it wh1sp3r, how can i do that? how can i load some terrains, when engine is designed to use only 1 terrain? well, looking like i can make a special tool, which will separate terrain into different parts, for example: i have a map 1 2 3 4 5 6 7 8 9 so tool would generate all combinations of maps into separate levels: 1 2 4 5 , next one 2 3 5 6 , next is 1 2 4 5 7 8 , and so on, but its not a good solution.

Or even smaller terrains? If i can walk through side of 2K*2K terrain for 10 minutes, then i'd be able to walk through 512*512 for 2.5 minutes... so, 3 little (512*512) terrains would give 7.5 minutes of walking. It would use less memory and give me access to infinity terrains. Then i would add LODs and so on, but i really need to use more than one terrain.

Maybe it would make a sense to work with not so large terrain? If we would use smaller one, for example 1000*1000

//The simplest thing you can do is set the meters per tile to 2. That will still give a good resolution, and you will quadruple your area, if it is set to 1.0 right now. We tested that, but we dont like resolution. //The terrain shown there is 1/4 the max terrain area, by the way. Yep, i know, but even 20 minutes is looking not enough... I noted that now it is possible to attach only 1 terrain per map. I dont ask "beautiful infinite system", but just a possibility to use more terrain per level, so we could load others dynamically (maybe with the help of multithread-loader).

I checked size of terrain... black line in the left down corner is about 3 minutes of walk. So, player can walk through terrain for about 12 minutes from side to side... well, thats not enough.

We really need dynamics terrain as fast as possible... Artists want so large scale of building, so we need dynamically loading of terrain and objects. As i remember, somewhere in forums there were discussion about dynamically loading of models into a memory in another thread and then copying it to Leadwerks. We can write this loader, but we can do nothing with dynamic terrain loading. Josh, can you help with it?

Moon looking very good, keep it up.

Thanks, thats very usefull.

How is your progress?

Sounds very good, cant wait to test it.

I'm also interest to know, what about GUI in Leadwerks.

I thought that Category:Surfaces is for hand-made meshes (like box in tutorial), i'll look deeper there, thanks.

In 3d gamestudio there is vec_for_vertex command ( http://www.conitec.net/beta/aent-vec_for_vertex.htm ), this returns position of the vertex in entity, so i can attach particle to pistol, or pistol to the hand and so on. The question: is there any function like that, so i can get and set positions of the meshe's vertexes (i'm going to make something like simple face generator)?

Just an idea: why not to add to the specification of the *.sbx format (in the second or third string) a parameter, which would show, how many entities are on the map. So, after loading each new entity, we can calculate how many entities remain, so we can know how many % we already load?

Understood, thanks.

I understand about global optimization (just played with forest demo-level), but... Well, so if i'd look at the terrain from close distance (so i'd see only some hundreds polygons, like on the right picture), engine would render 33K polys anyway?

Its just a simple terrain, but i didn notice any culling...

Here it is. BrokenPillar is absolutely right. PS: "Error You aren't permitted to upload this kind of file" I cant upload neither *.rar, nor *.sbx here http://uploadbox.com/files/ab6d3a81b7/

Emm.. I added to LUA require("scripts/class") local class=CreateClass(...) function class:InitDialog(propertygrid) self.super:InitDialog(propertygrid) local group=propertygrid:AddGroup("Stones") group:AddProperty("StoneNumber", PROPERTY_INTEGER ) group:AddProperty("StonePosition", PROPERTY_VEC3 ) end function class:CreateObject(model) local object=self.super:CreateObject(model) --load the stones self.stones=LoadModel ("abstract::Dec01.gmf") --position stones or use the offset by exporting self.stones:SetPosition(Vec3(-4,6,-0.7)) --parent stones to the main model self.stones:SetParent (object.model) --done with parenting function object:Free(model) self.super:Free() end end but still have physic on stones