the source engine.

[crackhead]

how come the source engine cant handle large outdoor maps compared to say the battlefeild 2 engline, whatever enging that is. i meen sure in the bf2 maps they have lods for the terrain but what if you made the terrain as models with complex collision models? then made lots of lods for each piece and made the map in parts. then would it be able to handle a huge out door map? its something to think about anyway.

 

[Inflame007]

well....
Valve didnt need huge scale levels so they didnt implent it.

 

[GonzoBabbleshit]

That would be the stupidest reason.

You don't design a game engine like that, unless you want it to be a really crap game engine

 

[crackhead]

hahahaha. well hes got a point. if they dont need it to be able to handle huge maps there not going to design it to be able to. my quetion was more of technically how come it cant , if it cant. not like why didnt they design it to but jsut what makes an engine be able to render huge maps. anyway im gong make a little test map of what i said about the seperate terrain pieces with lod models.

 

[GonzoBabbleshit]

They didn't build the Source engine exclusively for HL2.

The plan was to use it for future games and license it out, so to say they made it unable to handle huge maps because they didn't need it to is ridiculous.

 

[$kelet0r]

well his point is that the current source sdk cannot render large maps
and it more than likely comes down to the fact that the texture detail in hl2 is far too high and memory consuming - it is designed to make small areas look fantastic

 

[crackhead]

so your saying by simply using less texture detail you can render huge maps? i dont think so

 

[$kelet0r]

no because the source engine is coded to optimise textures in a way that not even the unreal engine does - thus it seems to concentrate on the immediate scene at hand
if you coded a large map with very low textures in source it would work - huge killboxes are proof of that
the problem is that a huge killbox stretching the source engine to the limit is still very small compared to what bf2's engine can do

a work around is to have a dynamic path follow the player as they move in the game world, a boy in the bubble concept where everthing up to a set limit from the player on a level is rendered perfectly while the parts that are not being used become static, low resource areas
however whether source can do that dynamically is highly unlikely

 

[Inflame007]

Well, source dosent have terrain lods, also it renders alot of things that arent on scane and it renders shadows and animations even if they are not needed.
And from what I have seen the mipmapping is still to detailed.
also, it has that annyoing thing that makes all textures blury in colse range.

 

[crackhead]

what exactly are mipmaps?

 

[$kelet0r]

What is Mipmapping?

Textures are hugely important to making 3D scenes look real. They are 2D images that can be applied to polygons to increase realism. Multiple textures can take up a lot of memory. Mipmaps helps to manage their size with various techniques. Mipmapping is a technique used by game engines to reduce the memory footprint and bandwidth demands of textures.

The technique of Mipmapping involves preprocessing a texture to create multiple copies, where each successive copy is one-half the size of the prior copy. When a 3D card has to map a polygon with a texture of a 1:1 relationship of 1 texel (texture element) in the original texture map corresponds to 1 pixel on a polygon. If the polygon you are displaying is scaled down to half size, then effectively the texture is displaying every other texel. This can occasionally lead to some visual weirdness. With mipmapping, you scale the image yourself, before the card gets at it, and since you can pre-process it, you do a better job of it. When the 3D card draws the polygon with the texture on it, it detects the scale factor and selects the correct texture.

6charity

 

[OCybrManO]

I think the problem is more than likely caused by the continuing use of the old binary space partition format that has been around in games since the original Doom. It's not really designed to work in large, open environments with rough terrain and other complex geometry. It works best in simple indoor environments. Also, since everything is stored into one big file, the operating system's maximum single file size comes into play. There are other significant limitations... but I'll leave them for some other time. They're going to have to drop the BSP format in favor of something that handles complexity better eventually... even if only because the compile times are slowing production down too much, as efficient use of time will be very important as games get much more complex. Other developers are already doing it. Even the people that first used it in games (id Software) have already abandonded it. Perhaps the next major upgrade to the Source engine should be support for a new map format and a more advanced lighting system (since, in the current maps, the BSP stores the lighting)... maybe by the time they do the next Half-Life game.

EDIT: For example, by comparison, the new Unreal Engine can have maps as big as you want them to be (at least, until your hard drive fills up)... because their format was designed to be streamed in when needed rather than loaded as one whole map. BF2 maps are just a heightmap, some textures, and some text files telling it where the objects are supposed to be... so, it's pretty easy to handle large open maps consisting mostly of terrain.

 

[$kelet0r]

^the above is a very good point - you can see in hl2 that the source that natural terrain is very poor while manmade rigid structures are picture perfect
the mathematics in the source engine seem to be more formal and not make allowances for random design

 

[^Ben]

Lower then scale of the models and FOV and you can have atleast 10-40 times as big of maps.

 

[crackhead]

thank you all for you input much appreciated. what do you think specifically of my idea though. to make the terrain as models with complex collision models and many lods. so your terrain is like patchwork. lots of pieces sitting next to each other. then the computer is only rendering alot of detail on the area your on.

 

[$kelet0r]

it could work on the other hand all the other models still have to be rendered within the draw distance which would place enormous requirements on memory
also how would you get static models like buildings to remain fixed to another model when you have collision detection on - if you ran into the building it would slide away 0.o
and how would you avoid gaps between the different models

just things to consider before you try it - i would say its possible, making it playable is another question...

 

[Angry Lawyer]

Cyberman's right, Source uses the Binary Space Partition model, while battlefield uses a different style.

-Angry Lawyer

 

[$kelet0r]

well AL whats your opinion on crackheads idea - is it feasible in bsp?
i say yay but very tricky to get right - too many problems with models overlapping

 

[^Ben]

kdtree_test

kthx

 

[Angry Lawyer]

well AL whats your opinion on crackheads idea - is it feasible in bsp?
i say yay but very tricky to get right - too many problems with models overlapping

It'd be difficult, but the big problems would come from the game trying to render all of the objects in the same sector - because assuming you're doing one huge skybox level, it'll try and render everything at once. And no matter how much you reduce the geometry detail, the computer still has to cope with the objects.

-Angry Lawyer

 

[FictiousWill]

OCybrManO is right on every front. Source is basically quake1 with higher texture resolution capacity and skeletal animation. The reason source can't support large areas is because valve would have to rewrite the engine to do that, which is the last thing they want to do. (In fact they're willing to go to ridiculous lengths to avoid working on the base quake1 engine, which is why there's a whole 3d skybox system.)

If you want to read my extensive rant on 3d skyboxes go here:
http://www.hl2-world.com/bbs/3-vt39614.html?postdays=0&postorder=asc&start=30
remove the hyphen in the link.

 

[crackhead]

kdtree_test

what does that meen?

well imna try it none the less. does this meen the future unreal engine will be alot better for modding then valve?

 

[$kelet0r]

crackhead you're on the internet - the repository of all human knowledge
google once in a while

its a java command for the placement of entities like nodes et al or in this case dividing maps into subsets

 

[crackhead]

lol dont you only use et al if your refering to a group of doctors or psychologists. hoffman et al etc. ? anyway yeah i was gona make an edit n say that when playing bf2 i often notice the terrain shifting and the texture resolution changing. so i assume its working in a similar way to how i suggested. with lod models. or maybe not.

 

[$kelet0r]

et al is french
et = and
al = all
damnit crackhead learn to google

no bf2 simply has set draw distances client side - it increases render detail as you get closer - textures are very clear when you get close to them unlike in source where they are fixed in scaleability (blurry textures when you're nose is up against them)
bf2's engine by all accounts seems to be far more hi-tech than source which is very lacking in some very big areas (map size, lighting, dynamic shadows, natural terrain etc.)

 

[crackhead]

whats google? anyway i stick by my idea.

 

[^Ben]

Some of the stuff that comes out of your guys mouths is great fun.

Especially Will's random ramblings on the source engine.

So it's just the quake 1 engine? Hrmmmmm, now wasnt that engine written in C? Refresh my memory.

And the way the doom 3 engine did it's map structure did wonders for it's outdoor enviroments, or should that be low res textures trying to simulate buildings? I forgot.

 

[$kelet0r]

Some of the stuff that comes out of your guys mouths is great fun.

Especially Will's random ramblings on the source engine.

So it's just the quake 1 engine? Hrmmmmm, now wasnt that engine written in C? Refresh my memory.

And the way the doom 3 engine did it's map structure did wonders for it's outdoor enviroments, or should that be low res textures trying to simulate buildings? I forgot.

he's not wrong when he says that source was built from the bones of the quake engine used for hl1 and so what if it was written in c? c++ is an extension of basic c
doom 3 is the extreme case of being able to handle indoor environments only
hl2 is just much better at closed environments than large outdoors for similar reasons - high res unscaleable textures and the limits of bsp

 

[crackhead]

the doom 3 engine did it's map structure did wonders for it's outdoor enviroments

wait a minute. doom 3 has outdoor maps?

 

[^Ben]

Got any proof to back that statement up?

 

[$kelet0r]

have you any to refute it?
simple logic - the engine design (caches, dll files and all) is very similar in layout to hl1s and they even use the same map type (bsp) - hell look in your hd folders for proof

c is an extension of c++ - whats wrong with that?

hl2 is just much better at closed environments than large outdoors for similar reasons - high res unscaleable textures and the limits of bsp
- any problems here? if you do any coding you will know this is the case and ocybromano explained bsp very well a page ago...

 

[Angry Lawyer]

Source doesn't use code from Quake 1, but it still uses Binary Space Partitions.

http://en.wikipedia.org/wiki/Binary_space_partitioning

-Angry Lawyer

 

[^Ben]

-snip-
But I can tell you, the way the files are laid out are very similar just like the console commands are, because the developers liked the way quake did it(but the source is completly different)

But then again, unreal hasnt changed file structure since unreal 1, so does that mean that unreal 3 is just the shell of UE1.

 

[$kelet0r]

Source doesn't use code from Quake 1, but it still uses Binary Space Partitions.

http://en.wikipedia.org/wiki/Binary_space_partitioning

-Angry Lawyer

yes source uses c++, quake used c
my point was the design of the engine was built from the bare bones of the quake engine which is true

But then again, unreal hasnt changed file structure since unreal 1, so does that mean that unreal 3 is just the shell of UE1.

isnt it, the same structure - you get the benefits and limitations that go along with that
imo the unreal engine is very poor still at collision detection - the issue of models looking like they float and are not properly affected by gravity is something that first came to light in Unreal (npcs running on the spot) and still has not been fully addressed (re Ut2004)- mainly because it would require a complete engine rewrite
no developer starts from the beginning, just as no builder will construct a house without blueprints and a foundation

 

[crackhead]

should i be taking notes?

 

[^Ben]

Are you a programmer? Just wondering.

The way files are laid out is just for familiarity, there is no design benefits on how the file structure is laid out or advantages(im talking about files, not a map structure)

Valve designed the engine in a COM like fashion which allows them to swap out all parts of the engine without ****ing up other parts of the engine. At the moment as can be seen by the SDK code and by console commands currently in the game such as kdtree_test(currently crashes my beta .exe but might work on non beta machines) shows that valve are currently in the process of evaluating/implementing a kdtree map structure.

Actually I want confirmation on file structures, are we talking about the same thing?

 

[$kelet0r]

kdtree commands are simply an algorithm to divide a map into segments around a kdtree node - its a common command in java for dividing an animation into seperate almost bordered entities which can then be remerged without starting a new applet
the only reason i can see valve using it is to eliminate loading points as much as possible in maps - a new segment becomes active as you pass the set node/point

Actually I want confirmation on file structures, are we talking about the same thing?

check the dll files for confirmation - they're not identical for convenience, they are almost identical because of the way the engine accesses them - the same way quake accessed them by the looks of things .... which clearly brings to mind why dynamic shadowing was not included in source - the original dll files did not exist for such a engine 'cog'

 

[^Ben]

Ok first up, kdtrees can be used for map structures, but as seen by HDR valve can and will take different approaches for what they feel is the best.

Second shadows.


"r_shadowdir"
client cheat
- Set shadow direction
"r_shadowangles"
client cheat
- Set shadow angles
"r_shadowcolor"
client cheat
- Set shadow color
"r_shadowdist"
client cheat
- Set shadow distance

Third, the way the DLL's are the same.

First up the HL1 engine.

http://img408.imageshack.us/img408/1982/halflife7pu.gif

Second Source engine

http://img408.imageshack.us/img408/8207/source0yb.jpg

So, the only dll files that are the same are tier_0 and vgui2, tier_0 is how memory is handled and how the engine knows what features you CPU has, so basically real deep stuff.

And VGUI2 was backported from Source to HL1.

So as I said tier_0 is basically how your CPU is deteced and how the engine interacts with it's features, not really something that's going to make a break an engine, infact I would hazard a guess and just say all engines tier_0 code i s just updated every so often to accomodate new hardware.

And are you a programmer? Because I don't think you get how DLL's work/can be used, and how it dosent really matter with what your trying to convey.

 

[OCybrManO]

the doom 3 engine did it's map structure did wonders for it's outdoor enviroments

wait a minute. doom 3 has outdoor maps?

Believe it or not, the map file structure of Doom 3 is actually not bad for outdoor maps. The lighting makes the organic outdoor areas look not so hot... and wide open outdoor areas on Mars aren't very scary compared to dark, confined spaces. For a better example of what it can do, Enemy Territory: Quake Wars is based on the Doom 3 engine and it does outdoor areas just fine. There are also custom maps for Doom 3 that were made to test the performance of large, open areas. The frame rates were good for the amount of geometry being displayed but they didn't look good.

 

[Pi Mu Rho]

Quake Wars isn't a straight Doom 3 content modification though - the engine was extensively modified.