Huge Worlds

I should also say.

You cant stop the bsp process splitting large blocks into many portals but you can help reduce the number of portals considerably also by making sure that blocks never actually overlap, which creates further splitting and many more portals. This can be painstaking by necessary if you want huge levels.

Do this by making sure all walls just touch each other using snap to grid or if possible never actually touch each other at all in places where you cant see the join, areas of darkness and so on. If under magnification (zoom) you just get them touching or aligning very closly but not touching and use high prec when you build your level the bsp processe will close the gap in many istances.

Unless you have bright lights behind minute cracks - in normal gameplay the player wont notice any that do remain - but you will save creating many extra portals this way.

Then you must ensure that you level is surrounded by a single hollow box (no gaps)or you will get uneccessary leak artifacts showing up even if the engine may not mind running the level.

It's do-able but build times would be a pain. Am I the only one who it seems to have been that with the 6.11 that build times are much longer? Maybe its jsut me....

Build times will be a touch slower I am guessing because of the better lighting and new collison detection. Haven't really ran any long builds to compare the two, but it would make sense.

From what i've seen of A6 so far it appears on the outset to be a big step backwards with little obvious improvements...

However now that we are playing with it more it becomes clear that nothing is further from the truth. The 32bit images really improve the smoothness of shadows, sprites and other such imagery. The editing tools are greatly improved and now have more incommon with other code tools like borlands C++.

We have experienced some strange Nexus restrictions/requirments and the overall speed of the engine seems to be the same at best, but we are yet to explore this so i can not comment......

BTW: Regarding large city scapes or gameplay areas like GT:III VC I can say this:

Play GT and watch to see how they do it. In my opinion they simply combine all the trickery available in GameStudio in an almost perfect way. They combine simple models (like palm trees) with sprites (like the palm leaves) to reduce strain on the processor, the terrain is constructed in smaller 'tiles' to help clipping, and they use 4 levels of detail...

The buildings themselves are a combination of textured simple map blocks and models which you can not enter as they are just blocks.

Finally the people that populate GT and their cars are spawned and removed as you drive around. You will have noticed that NPC entities that leave the immediate vacinity are gone for good as they have been removed.

Finally to help your render time, construct your buildings as map-entities as
this will greatly reduce your compile time.

Hope that helps....

well, first, you gotta know that games like gta 3(or vice city) are made as loose modals. Every part of the "city" is a modal. As in, every building and stuff. For this to work in 3d gamestudio you could make models (of buildings) or map entities. And in one map just glue 'm all togetter, without using blocks. Just the models. You will see that the build time will be around 1 or 2 secs. No matter how big your map is. And it will work. Even on low-end pc's. cuz modals are loaded on sight and aren't hanging around in the video memory when they are out of sight for the player. (blocks and prefabs do that)

Worked for me

Let me just ask a question or two to try to get my mind straight on all this. It seems to me to be an important issue. Does everyone agree with robindegen that using models for buildings will compile faster than blocks? I understand that models don't work as well for collision detection, right?
But what about the fps when the game is running? What is the trade-off there? Do models slow down gameplay? Would it make any sense to make the first floor of a building out of blocks, then drop the rest of the skyscraper on top as a model? The first floor would have good collision detection, and the model would just be there for looks? Does it make sense to use models for buildings if you can't get up next to them?
I have built some fairly large levels out of blocks, and am hitting some FPS and build-time issues, and have not much in the way of NPC's added. So some discussion of this would be helpful.

Hi,

i can give also an example to make huge worlds: make all smaller: For example, i am currently making Dark Age a Role-Play game with a huge(huge)-world. I made the Players Size to 4 Quants. so the world is small and you can extend it very much. For things that are smaller or require more poratls i make a wmb file. all "sectors"(Mountins, cities) i have compiled into a wmb file. later i get them together in a main map.
Plane:

Code:

---

  
| & - =  Level Borders
/ & \ = Hights
S = Sector borders
|--------------|
| /\     s /   |
|/  \    s \   |
|sssssssss  \  |
|    /\  s   \ |
|--------------|

---

wll its not good explained but it shoul help you. What i mine is: Make all smaller to get more space to construct a huge world.

cu
XWCG(blue)

Hiya,

I found a good turtorial for the torque engine. It gives some ideas about how they use LOD and detail blocks to reduce poly counts on there large outdoor areas. Although its specific to torque which is designed for massive outdoor worlds, some of it can be applied to GS..

Torque Map Tutorials

You are right, collision dection isn't as good, so keep your models simple, again look at GTA's simple block buildings.

A shot in the dark, but doesn't setting the 'detail' flag on faces you will never see prevent extra portals from being created?

This has been most enlightening... and, at the risk of stepping all over my, errr two feet, here...

... I would think that dynamically loading separate entity maps as described in a previous thread (treadmill technique) might be the best way to implement an unlimited large scale world.

This would appear to eliminate the long build times, and all other problems associated with large scale world construction...

... and this method would also seem to allow an unlimited world size, ideal for flight and naval sims, or massive online worlds where users can construct their own lil properties and such.

I'm gonna try something like this in a few days... if I get it started reasonably soon, I'll post the results here.

--Mike

Here's another suggestion. I'm in the process of creating a huge world too and I'm mainly using models for my buildings and so on. To avoid the whole problematic collision with models (where players walk right through them) I've placed invisible blocks/cubes around, to get good collision. I've created a world with 4 labyrinths in it where the walls are models surrounded by these invisible blocks.

I had a problem for the ground though. I want to use fog, but when I created my ground from a block I always get the 'to big for shaded' error. Tried to use very small blocks to no good either. I can set the texture to flat, but then the whole texture dissapears becasue of the fog (I get one huge red plane --- red is the fog color used). Here's what I ended up doing. I creaed a huge block as my ground and made it invisble. On top I placed the texture I wanted as a ground as a sprite, duplicating as much as needed to cover the whole area. This works very well and no demand on the frame rate at all.

Perhaps buildings can be constructed this way to, by putting together sprites and placing invisible blocks around them...... this would give a great framerate.

At the moment I'm still using models, since the walls are a bit detailed in shape. At the moment my level is 16000 x 16000, it has far over 300 models in it (10 different models, duplicated lots of times), about 60 mountains (10 different hmp files), using fog, and I still get a framerate between 50-70. Except for at the biggest labyrinth, when looked at from one certain side, the framerate drops to 40, as soon as you go one step closer or further away the frameratr goes up again. Building time of the level is around 3 secs.

I dunno what happen with small blocks (acording to the manual its not convenient to use them smaller than 2quants).

Other engines have a kind of block that produces manual PORTAL SPLITS:
A block not renderizable nor visible, but acts like PORTAL in every surface.

So, u could place it into a valley as a "cieling". If u are climbing the hill to the valley's town (with hy polycount), the town will not render untill u reach the top of the hill.
Or if u are outside of a castle's wall with a tall Keep in the highly detailed inner yard, u could place the "PORTAL" block sized to fit the inner yard an as tall as the walls. The engine should render only what u realy see, leaving the inneryard unrendered till u enter or climb ontop the outer wall.

IS ANYTHING LIKE IT IN THIS ENGINE?????

sry i didn't reply erlier. I've bin kind of busy. I admit that complicated models have bad collision detection. It will make the game slow to! I found a program on inet that can export GTA (3 and Vice) buildings\models to 3D studio MX models. Which can be exported to gamestudio models. With a little editing, you will have prefabed buildings, bridges and alike (just give them a new skin and edit a bit)

Note: The models in GTA aren't that complicated, and if they are, it are multiple models (like the broken bridge in GTA 3).

Gamestudio doesnt have hint blocks or portal brushes or anything like that, what you can do to block rendering is setting a blocks faces all to none texture flag
the only problem with that is the block gets rendered solid black, so there pretty much usless for blocking items behind them. It would be great if map entitys would block rendering, but they dont!, so if you have door map entitys with a very detailed room behind them, when you look at the doors everything in the room behind them gets rendered as well.
Best thing to do is use curved hallways and things like that, because you can slow it down to a crawl if you have lots of long straight shaded areas, even worse if your adding terrain into the mix

Golum, thank U very much!!!
"Can slow it down to a crawl if you have lots of long straight shaded areas, even worse if your adding terrain into the mix"
Sadly, i went for an outdoor battlefield to test!! All polys are exposed and rendered, even behind uncapped surrounding tall walls...
.
Maybe someone experienced could use the numeric FLAGS (in the properties/surface tag) to attach a script or something else that behaves like a HINT BRUSH. (wander if that could be possible?)
Anyway, thanx again.

You'll need to be signed into Gamasutra to view this article:

http://www.gamasutra.com/features/20010322/coates_01.htm

I figured it belonged here...here's another thread that I posted at the beginning, but it goes with this one:

http://www.conitecserver.com/ubbthreads/showflat.php?Cat=&Board=UBB9&Number=175424&Forum=All_Forums&Words=city%20size%20levels&Match=Entire%20Phrase&Searchpage=1&Limit=25&Old=allposts&Main=175424&Search=true#Post175424

sorry to be offset here, i guess? I only had time to read the beggining of the thread. Anyways, i was thinking, havnt really tried this yet, but would it make it faster to make all the walls of the building using sprites, and then adding the details through models, and finally having a "floor" and sidewalks as wed entities?



Amigo