Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Work in Progress / BlitzTerrain

Author
Message
Duffer
21
Years of Service
User Offline
Joined: 9th Feb 2003
Location: chair
Posted: 10th Sep 2009 22:31 Edited at: 10th Sep 2009 22:31
@ The Wilderbeast - cool. What a fantastic complimentary utility that's going to be - especially you can export out to DBPro and import in to DBPro with water and bloom shaders....

a long time dabbler with DBC and DBPro with no actual talent but lots of enthusiasm...
kaedroho
17
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 12th Sep 2009 17:21 Edited at: 12th Sep 2009 17:34
I just got a cool idea! This is how the system will handle multiple cameras. A very optimised way.

Lets say we have 3 cameras. 1 main, 1 for water reflection and one for bloom. The bloom camera will have to be at the same position and rotation all the time and the reflection will have to be at the same position but inverted x rotation. So why recalculate all LOD and frustum culling before rendering each camera? Well, heres a solution. Heres how the update command will be made.

BT Update updatemode.

and the update modes are:
0 - copy from previous camera
1 - update frustum only
2 - update LOD only
3 - update all


So this is how the above example will be updated:




The frustum culling will use object masking (look at set object mask) so it can hide objects in some cameras and show them in others.

Using this, you can make it so it only updates when the player has moved/rotated, another massive speed increase.

draknir_
18
Years of Service
User Offline
Joined: 19th Oct 2006
Location: Netherlands
Posted: 12th Sep 2009 18:22
The DGDK demo worked great, but when I run the DBP demo it crashes with 'could not find MFC71.dll' and 'failed to load enhancements.dll'.

Also I was wondering if you could compile a GDK version without the vsync? I'd love to know what kind of FPS GDK + your plugin can achieve on terrain.
kaedroho
17
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 12th Sep 2009 19:02 Edited at: 12th Sep 2009 19:13
I'm not good with GDK. I have included all the headers and libs you need to use blitzterrain. And the source code for the demo. Maybe someone else can do it.

MFC71.dll can be downloaded from dllfiles.com .

Xenocythe
19
Years of Service
User Offline
Joined: 26th May 2005
Location: You Essay.
Posted: 12th Sep 2009 21:32 Edited at: 12th Sep 2009 21:40
Wow, taking away LOD and frustum culling definetly leave a big gap in the FPS.

The GDK version re-compiled fine, when you put the media folder in the correct place. Everything is looking awesome man!

thenerd
15
Years of Service
User Offline
Joined: 9th Mar 2009
Location: Boston, USA
Posted: 12th Sep 2009 22:16
yeah, the LOD is really a nessecity.


forever loading...
kaedroho
17
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 12th Sep 2009 23:02
Working on frustum culling as we speak!

Xenocythe
19
Years of Service
User Offline
Joined: 26th May 2005
Location: You Essay.
Posted: 12th Sep 2009 23:05
Nice! Keep me posted on msn

kaedroho
17
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 13th Sep 2009 01:12
Ok, frustum culling is now working! Its super accurate too, if you cant see terrain, it wont draw terrain! Unlike what DBPro frustum culling does. Just got 1 minor bug to fix and I might get to release a demo tomorrow (Its a little late here in the UK).

James H
17
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 13th Sep 2009 01:37
Haven`t been around in a while and just got back into DBP; downloaded the latest demo of this and gotta say nice work man! Looks real good, will be playing round with it real soon, cheers
Visigoth
19
Years of Service
User Offline
Joined: 8th Jan 2005
Location: Bakersfield, California
Posted: 13th Sep 2009 06:25 Edited at: 13th Sep 2009 06:26
ok, I'm confused. Am I doing something wrong? I ran both demos, and I didn't see any LOD. I ran it in wireframe and never saw any LOD switching. The stats reported the same amount of polys. Maybe I don't know what this demo was supposed to do. To me, it looked like a limbed terrain with a texture. Was there supposed to be some LOD?
kaedroho
17
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 13th Sep 2009 12:38 Edited at: 13th Sep 2009 12:44
Your thinking about the old version... or the new version in a few weeks.

I recently just rewritten the whole entire thing. I just added Frustum culling back in (the demo doesn't have). I'll be working on quadtree frustum culling today, and I'll start on LOD tomorrow.

The loading speed is now 40x faster than the old version, deleting terrains is possible to do (no shared arrays). Some other bits and pieces have been added. I'll write a few pages about changes that has been made a bit later.

kaedroho
17
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 13th Sep 2009 22:31
Object masking is working absolutely perfectly. Each camera has its own Frustum culling, meaning that instead of camera 1 drawing what's in camera 0 and 1s frustum, it draws only what it can see. Object masking basically allows you to hide objects in certain cameras.

You can also make a camera copy frustum culling data from a camera. For example, say you have a camera which is always at the same position and rotation of another (like a HDR Camera with the main camera) what's the point in recalculating the culling? Simply copy it over.

kaedroho
17
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 17th Sep 2009 22:54
Sorry for lack of updates, I have been working on LOD recently. I'm redeveloping my LOD algorithm, It will look similar on the outside, just be a lot faster. My original algorithm took 6 months to develop. One of the optimisations I'm doing which is taking the most time is changing the vertex order to put the vertices around the edges first on the list. This is so I can use the DirectX vertexdata locking system which allows me to lock only some parts of an object, in this case, the edges. This will make the LOD switch speed alot better, allowing for more switches and better Frame rates when travelling quickly.

Morphing is also in my head, getting rid of the popping. I will have to look into ways on doing this, quite honestly, I haven't got a clue. I can control limbs transparency using the DBP internal structures, that's about it so far.

James H
17
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 18th Sep 2009 00:47
Just a thought maybe vertex animation/control perhaps with bones and weights - movement towards matching vertex points in the adjacent meshes - or even look at possibility of vertex shader(might require texture lookups for heights or some sort of array access - dunno if thats possible though). Battlefield 2 employs vertex movement but its still noticable, could be a performance hit too. Then again transparency could look odd with other objects in the scene as they can be seen behind the smallest of hills - unless there is a way to prevent this with shaders or duplicate LOD objects(ie don`t lose the older LOD object until the newer one is fully visible - but then there might be zbuffer issues). Maybe consideration should be taken into what transitions would be best for what type of game. I think perhaps you should leave the current method as is - and concentrate on making this sellable if thats still your plan?(I haven`t had time to read all the posts I`ve missed yet). Hmmm, just thoughts.
kaedroho
17
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 18th Sep 2009 14:32 Edited at: 18th Sep 2009 14:33
James H,

Thanks

I would say that morphing is better than popping. I'll look into doing that with vertex shaders later on. I'll get LOD working first. Last night I got it to generate multiple LOD levels. Now the system creates all the limbs together, instead of making all the LOD Levels separately then merging them into one. Very small loading time increase. Loading speed test: No LOD = 500ms, 3 LOD levels = 700 ms.

I'm going to release the full version for free, but advanced features will need to be unlocked with a piece of software. I'm doing this to make it a lot easier to prevent piracy. Plugins are just files, they can be copied anywhere. This will also mean that you will be able to use things like streaming and spherical terrains for free, but you will not be able to make them with custom media without the software.

KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 18th Sep 2009 18:17
Sweeeeeeet...

Can't wait til release !!

kaedroho
17
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 18th Sep 2009 23:36 Edited at: 18th Sep 2009 23:38
Thanks.

Sorry, those results are wrong. They were from the Debug version.

The actual results from the release version are

No LOD: 210ms
3 LOD Levels: 280ms

you could probably generate a terrain and delete it once a loop at not a bad FPS with that!

kaedroho
17
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 19th Sep 2009 01:43 Edited at: 19th Sep 2009 01:45
I'm going to restructure the internals slightly, make it point to sector meshes instead of objects, this will make it possible to add some more commands.

If you call BT SetMainObject terrain,objectnum for a terrain, that terrain will not need you to create an object for every single sector, meaning, it creates a limb for each sector instead. The same can be done for physics. I was going to add this before, but my ideas about "Advanced Physics" sort of got added first and the normal one never got added.

Profit
18
Years of Service
User Offline
Joined: 19th Feb 2006
Location: United States
Posted: 19th Sep 2009 01:58 Edited at: 19th Sep 2009 02:09
we share the same avatar.


Visigoth
19
Years of Service
User Offline
Joined: 8th Jan 2005
Location: Bakersfield, California
Posted: 19th Sep 2009 07:10 Edited at: 19th Sep 2009 07:11
@Profit
very observant. How does this help this thread?
also, I just LOVE it when you download a demo, and you get like 1000 other windows popping up...nice
kaedroho
17
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 19th Sep 2009 16:13
Profit, cool!

Visigoth, Glad you like it.


More plans. I'm going to give the collision its own exclusion mapping system. In some cases, you might want to use different exclusion, like areas where the player cant go, you would want visual, but not physics. This allows for more optimisation.

LOD is almost done, the reordering of vertices for speed is a little tricky though, but should bring a massive speed increase in LOD switching.

Sector Mesh optimisation will be finished shortly, this just deallocates any extra data that isn't needed, realtime exclusion and realtime reduction will need this to be disabled though. I believe I can get my reduction algorithm fast enough, its still very basic though. I haven't came up with a method to reduce it by more than 1 level yet.

For those who don't know what realtime reduction is, it basically works with the RTMS and works out which parts need higher detail than others, it will do this as you edit the terrain. This will require some fast algorithms though, but I have methods of changing the meshes very quickly in realtime.

I might actually rename RTMS to RTTMS. RealTime just sounds like time should have its own letter, and I keep accidentally saying RealTime Modification System.

Currently, I'm working on making it so it generates a terrain in 1 object, might acctually fix the pinholes.

The Wilderbeast
19
Years of Service
User Offline
Joined: 14th Nov 2005
Location: UK
Posted: 19th Sep 2009 16:29
Quote: "very observant. How does this help this thread?
also, I just LOVE it when you download a demo, and you get like 1000 other windows popping up...nice"


And how exactly does that help the thread? Perhaps if you gave some indication of why they might be appearing, or perhaps you might even be so kind to tell us what is inside the windows?

kaedroho
17
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 19th Sep 2009 16:31 Edited at: 19th Sep 2009 21:05
I have got error messages with the demos. Its caused by missing dll files in your system32 folder. These dlls have nothing to do with blitzterrain. If you have DBPro, you should have them. DBPro needs them to run any project.

EDIT: Cancelling the plan to make terrain 1 object. My frustum culling system won't work with limbs. This is because it uses object masking which can only be done on objects. Its also made my code very messy!

The loading speed went down to 150ms when I made it all 1 object.

I have also deleted every command with the UT prefix. People who are still living in ancient times, just change UT to BT, and it should work like normal.

Duffer
21
Years of Service
User Offline
Joined: 9th Feb 2003
Location: chair
Posted: 25th Sep 2009 00:28
@ kaedroho - problem is we are used to near hourly updates on your progress on this superb plugin - and now we have been waiting 5 days - outrageous - almost as long as we would have to wait on any other thread....

a long time dabbler with DBC and DBPro with no actual talent but lots of enthusiasm...
kaedroho
17
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 25th Sep 2009 12:07 Edited at: 25th Sep 2009 12:08
Oh yes, sorry. I have been working on a few things recently. Such as a demo which is a project inside the BlitzTerrain solution. Which means that it compiles straight from the BlitzTerrain source code. This means that it saves me having to compile a dll, move the dll to the DBPro folder then compile my demo, just to test simple features. This will increase the development speed by quite a bit.

I have also been messing around with some of DBPros internals. Trying to find as many things as I possibly can to speed up BlitzTerrain and DBPro.

Azunaki
15
Years of Service
User Offline
Joined: 11th Feb 2009
Location:
Posted: 26th Sep 2009 01:54
...>>?

trying to confuse us?
lol

[url]http://myportfolio.x10hosting.com/[url]
visit my site.(still in progress)
Duffer
21
Years of Service
User Offline
Joined: 9th Feb 2003
Location: chair
Posted: 26th Sep 2009 11:53 Edited at: 26th Sep 2009 11:56
@ kaedroho,

excellent - thanks for the update.

In terms of priorities, what sort of order are you focusing on the remaining commands and utilities? What sort of order for these:-

a.Load/Save BT Terrain Commands
b.RTTMS Commands - paint terrain point
c.RTTMS Commands - further brush commands
d.[multi] Terrain Streaming
e.spherical terrains>?

how goes progress?

[edit]

also, with environment=BT GetPointEnvironment(terrain,x#,z#) is 'environment' a dword (ie equivalent of a 32 bit colour) or just a byte - 0-255?

a long time dabbler with DBC and DBPro with no actual talent but lots of enthusiasm...
kaedroho
17
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 26th Sep 2009 21:19
Environment is a dword. It isnt the same as the colour, its just an index to allow the system to quickly lookup the environment.

I will have to get LOD done first. I will do loading and saving commands after that. Then I will release 1.06.

I've just been overloaded with schoolwork recently, and I met some girl (thats all im gonna say about that) so im starting to see more daylight than I used to. Its a little harder to get motivated when you have a normal social life (well, more normal than it used to be!).

Must get LOD finnished soon. I have been working hard over the last week to make the LOD switching super fast. I have successfully created LOD meshes, but haven't switched them yet. Also, I have discovered that my object masking may not work in GDK. Unless I find the command to set the object masks.

Mista Wilson
16
Years of Service
User Offline
Joined: 27th Aug 2008
Location: Brisbane, Australia
Posted: 27th Sep 2009 12:49
There is no command in GDK to set object masks, you need to get the sObject pointer to the object with dbGetObject(int id) method. Using that pointer, you can manually set any object property you like, from simple things like the masking, to more complex things like manually adding/altering shaders and using shader arrays from inside GDK.

Here is the method I use to change object masks, its a simple functions, returns true or false depending on if it works :



Good luck with the LOD, ive been playing with my own terrains and various LOD algorithms, settled on doing the work in the programmable pipeline in the end(vertex shader), made it easier to matchup seams.

If it ain't broke.... DONT FIX IT !!!
kaedroho
17
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 27th Sep 2009 14:13 Edited at: 27th Sep 2009 14:45
Yeah, I used that. But it doesn't work on the last object created. So there will always be a sector not visible unless I create a box straight after. The actual command somehow does though.

LOD is easy. I've always liked to copy and paste my code from the original terrain engine. (BT 1.05 uses the exact same seam fix code as UberTerrain which was made in october 2008). It wasnt so easy to make it the first time though. I'm rewriting this algorithm so it uses the DirectX locking system to only lock parts of the object that need to be locked. Should increase FPS when doing loads of LOD switches.

I could actually optimise that slightly, as I keep the pointer to the sectors sObject inside the structure.

EDIT: That method WORKS with GDK. But now doesnt do a thing to DBPro. I'll just make the DBPro version use one way and DBPro use the other.

Thanks!

kaedroho
17
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 27th Sep 2009 15:25 Edited at: 27th Sep 2009 15:28
Deleting function is working. Unfortunately, there is about 2MB/terrain memory leak somewhere. I created and deleted 100 terrains and RAM usage was about 250MB. The Ram usage of BlitzTerrain is about 30MB/terrain.

Mista Wilson
16
Years of Service
User Offline
Joined: 27th Aug 2008
Location: Brisbane, Australia
Posted: 28th Sep 2009 05:27
Quote: "DirectX locking system "

Do you mean locking vertex/index buffers ? Doing that alot is something that is not reccomended for efficiency reasons. Locking and unlocking vert/indice buffers is an expensive operation, just something to keep in mind, perhaps a profile to see if you are actually getting an advantage from it would be a good idea. When I say profile, I dont mean FPS with locking versus FPS without, you would need to take into account time elapsed per lock/unlock operation, and other things like that, the time that your cpu spends calculating is the important thing.

That said, im sure that you would see some increase in speed, the operations may be expensive in terms of cpu processing, but not doing it at all is probably more expensive lol (of course, throwing it all at the GPU and saying "you do it" would be faster again lol)

The above was part of the reason I settled on doing most of my work on the GPU, you take the need to lock and unlock vertex buffers out of the equation, increasing efficiency and removing one of the fixed function bottlenecks. The rest of the reason was due to efficiency of GPU vs CPU for this kind of calculation(with GPU's winning hands down), and my own personal preference of course lol, as there will be no fixed functions pipeline in the future(dx10+ has none, its all programmable) I figured now is as good a time as any to learn lol

Quote: "That method WORKS with GDK. But now doesnt do a thing to DBPro"


Unfortunately thats correct, the dbGetObject() command is only available in GDK, it returns a pointer to the sObject, which is basically the DBO structure of the object(have a look at DBOData.h to see the actual data you can get at with the sObject pointer) I dont know DBPro well enough to say if there is an alternative way to get at that data from DBPro itself, but I would assume you would be able to get at the object's internals somehow.

The other option would be to have your code setup in such a way, probably using pre-processor directives, to compile one way for DBPro and another for GDK(you probably already have something similar by the sounds of it). You could have the compiler use the commands that work for GDK when its being compiled for GDK, and the others when its being compiled for DBPro...

The pre-processor conditionals would be one easy way to get it implemented, though you would probably have to refactor your code slightly, another would be to wrap the commands in your own "blitzterrain" version in seperate headers, so, one include for GDK, one for DBPro... they both have the same functions by name(BT_SetObjectMask() for example would be named the same in both includes, but its implementation would be different in each include) but depending on if you are compiling for GDK or DBPro would determine which of the 2 includes to use(again a simple pre-processor directive could be used to determine which to include).

If it ain't broke.... DONT FIX IT !!!
kaedroho
17
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 28th Sep 2009 19:21 Edited at: 28th Sep 2009 19:28
Quote: "Do you mean locking vertex/index buffers ? Doing that alot is something that is not reccomended for efficiency reasons."


I have already done it. In the past I used the vertexdata commands to do it for me. I just made a simple function to make DirectX lock the vertex buffer, DirectX allows you to lock only parts of it.


Quote: "Unfortunately thats correct, the dbGetObject() command is only available in GDK, it returns a pointer to the sObject"


Fortunately, that isnt correct, the problem is setting the camera mask bits using the pointer. Not the get object command. DBPro DOES have a get object command, it isnt in the string table though so DBPro users cant get to it, but plugin developers can.


Quote: "The other option would be to have your code setup in such a way, probably using pre-processor directives, to compile one way for DBPro and another for GDK(you probably already have something similar by the sounds of it). You could have the compiler use the commands that work for GDK when its being compiled for GDK, and the others when its being compiled for DBPro..."


Thats exactly what I did.



Mista wilson, Thank you for all your help. But most of that was stuff I already knew. Why don't you try out some of the demos and beta 1.05. You might be able to find something I need help with. Anyway, Thanks again!

Matty H
16
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 28th Sep 2009 23:26
Hi Kaedroho, have not read through all 18 pages of this thread so I'm sorry if I'm asking about something that has already been covered.

I noticed you plan to apply physics to your terrain system, have you started this yet?

I am currently working on the physics for Techlords Dark GDK open source project, I have not got very far as of yet but from looking ahead I realise that terrain physics is intrinsically linked to creating the terrain.

I was wondering if we could help each other, I know Techlord has asked about this in your DarkGDK thread and I think he has one eye on Blitz-Terrain for the project, let me know what you think.

I am using PhysX and I have got basic shapes sorted, I have tons to do, my next task will be to document what I have done so far with some examples/tutorials, as it is an open source project and the physics is a huge task so I will probably be trying to get people on board at some point to help.

Anyway, if we can't help each other, good luck with Blitz-Terrain.
kaedroho
17
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 29th Sep 2009 13:49 Edited at: 29th Sep 2009 14:29
Physics can be applied to blitzterrain objects.

When you build, every sector has its own object. This is so it can do object masking (allows for very efficient frustum culling). There is also a parameter to create a physics object. If you download version 1.05 and click the link to the help files, you'll see.

The physics object is a terrain object with only 1 LOD level. This LOD level can be set using the command BT SetCollisionLOD terrain,LOD. If you set the LOD parameter to 2 then the LOD level of physics objects will be reduced. 3 will reduce it more, etc. This will allow for better physics optimisation.

Another good physics optimisation that Blitzterrain gives is the fact that the physics objects are split up into separate objects. This allows you to use the command phy set object collision off/on And only activate physics for sectors which have a nearby dynamic object. This gives a very large speed increase. This was a feature of the original TGTE (TurboGames Terrain Engine, before it was renamed to UberTerrain).

It ran at 40 FPS without the optimisation. And 90FPS with the optimisation. This was a 256x256 terrain, 20 dynamic boxes and 1 dynamic sphere, I was using onboard graphics at the time.

Matty H
16
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 29th Sep 2009 15:56
Thanks Kaedroho, I am just trying to find my bearings when it comes to terrain. I have tried the GDK example and have looked at your help files.

From looking at the PhysX examples it seems that for best results I need to build a physics terrain, therefore I would need all the vertex data etc..
Will this be possible with BlitzTerrain? Is it even possible with the DarkGDK terrain commands? Does BlitzTerrain use the db terrain commands?

Sorry about all the questions, I am learning all this from scratch, none of my half completed games ever needed terrains for one reason or another.
kaedroho
17
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 29th Sep 2009 21:40 Edited at: 29th Sep 2009 21:43
Blitzterrain is its own terrain engine made from scratch. But the objects are DB objects. You can get the vertexdata for each object by making your engine remember the object numbers parsed to the Continue build function.

The highest LOD level is always limb 0. Seccond lod level is always limb 1. Third is limb 2, etc

The first sector to be made, is the sector which is closest to point 0,0. The last sector to be made, is the sector in the far corner to 0,0.

Sectors are made line by line. The amount of sectors per line is the same as the split (set with SetTerrainSplit). And the amount of lines is also the same as the split. A line goes along the Z axis.

thenerd
15
Years of Service
User Offline
Joined: 9th Mar 2009
Location: Boston, USA
Posted: 30th Sep 2009 01:59
question, will the new version have the same command set as 1.05, only faster, or will it be different?


forever loading...
kaedroho
17
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 30th Sep 2009 12:39 Edited at: 30th Sep 2009 12:41
Mostly, Some commands have been removed/changed/added.

The commands have changed are:





Removed Commands:


Added commands is changing all the time, so I wont post that just yet.


All commands have been optimised and made alot faster.

Matty H
16
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 30th Sep 2009 16:13
Thanks kaedroho, I will let you know how I get on.
kaedroho
17
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 4th Oct 2009 21:31
I have been recently changing the way the system works. So I can add this LOD system I thought of about a week ago.

As well as polygons, a big speed problem (probably worse than polys) is draw calls. When DBPro tells an object to draw itself. By adding LOD to objects you are only reducing the amount of polys being drawn. This is not decreasing the amount of data that gets sent to the GPU as vertexdata is stored on the GPU. The best way to reduce this data is by merging objects together and drawing them all in 1 go.

The new LOD algorithm will make lower detail sectors bigger than high detail sectors. Sectors will become twice as big every LOD level. This will allow you to squeeze as many polys as you can to a sector, and reduce draw calls. Also, Frustum culling will improve as less checks will be needed.

Visigoth
19
Years of Service
User Offline
Joined: 8th Jan 2005
Location: Bakersfield, California
Posted: 5th Oct 2009 05:03 Edited at: 5th Oct 2009 05:37
yup. Doesn't matter if you have 3 polys or 10,000 polys. An object is an object. Might as well send all you can while you are at it. I knew this many moons ago, which was the whole reason for poly reduction instead of fixed grids. Of course, it is possible to even make reduced poly grids even more efficient if you know how many polys you have after a reduction, and, just add them to a mesh as another mesh to make a bigger, singular mesh. The real killer is, and has always been, the number of objects being rendered, not the polys. This is the same concept of the "lots of billboarded trees" from along while back. The only thing you have to remember is, there is a limit to how many "faces" or, polygons you can have in a single mesh, and, that is like 64k, roughly. After that, its limbs, or, other objects, and, in my tests, other objects is more efficient than limbs, in most cases.

edit:
to better explain what I meant about fixed grid versus reduced polys. Since there is a limit for a single mesh, at 64k, and its a fixed grid, evenly spaced, all points on, the biggest single mesh you can make is something like 104x104 before it craps out. I might be off a few points here. That is why programs like Milkshape limit you to 64x64 heightmaps. Now, if you reduce the number of points based on how detailed you want the grid, you can increase the size of the grid, which is why I was able to get up to 256x256. I could go up to any size, but, the bigger it gets, the less "resolution" there is. With fixed grids, sure, you can sample points every point, for a 64x64 grid, or every other point for a 128x128 grid, or every 4 points for a 256x256 grid. But, you lose detail when you do it that way. That is why 1/3" DEM's are better resolution than 1" DEM's. There are more samples more often. Think of terrains like sound files. The more samples you have over a certain time is just like samples over distance. At times, or distance, there might not be much change. In sound files, those samples are eliminated, its a variable bit rate algorithem. With poly reduction, your only variable is height. If there isn't a big change between two points, no need to display that point.
The only way to make this happen was some sort of triangulation algorethem. It is real easy to filter the points, based on height, but, its hard to make a bunch of triangles out of them. Delaunay triangulation is the current method used to triangulate a random set of points into a list of triangles.

Sure, if sectors are far away, they don't need detail. They only need detail if they are up close. My arguement is, if you have detail where you need it, you don't need other detail levels. No need for LOD.
Duffer
21
Years of Service
User Offline
Joined: 9th Feb 2003
Location: chair
Posted: 5th Oct 2009 21:11
@ Visigoth & Kaedroho,

LOL... At this rate you two could publish a short book on the subject...

@ Kaedroho - how goes it?

a long time dabbler with DBC and DBPro with no actual talent but lots of enthusiasm...
KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 7th Oct 2009 02:20
Shhhh... Let him finish it first..

kaedroho
17
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 7th Oct 2009 18:36
Hey, sorry for lack of updates.

Another optimisation is on the way. Most of the update code for blitzterrain is setting values for DBPro. Also, DBPros object rendering system isn't specially designed for terrain. I recently discovered that you can make and draw objects without needing to use DBPro. So, I now have came up with a mad idea to make a fast terrain rendering system separate to DBPros rendering system. This will mean faster rendering and no need for Object IDs.

I'm going to get this in before I finnish the new LOD algorithm.

BMacZero
18
Years of Service
User Offline
Joined: 30th Dec 2005
Location: E:/ NA / USA
Posted: 8th Oct 2009 02:17
Quote: "So, I now have came up with a mad idea to make a fast terrain rendering system separate to DBPros rendering system. This will mean faster rendering and no need for Object IDs."

What will that mean for Z Depth with DBP objects? And will they still be compatible with Sparky's and DPhy?

Mista Wilson
16
Years of Service
User Offline
Joined: 27th Aug 2008
Location: Brisbane, Australia
Posted: 8th Oct 2009 06:41 Edited at: 8th Oct 2009 06:42
If they are no longer DBPro objects, then both of those issues could be problematic. Z-Depth is pretty easy to solve when using native directx and DBPro, and is related to the order DX draw calls are made in. The Sparkies and Physics would be harder to workaround if the objects arent DBPro objects anymore. Collision could be coded straight into the terrain engine quite easily to get around the sparkies, but Im not sure what would be the best way to approach DPhys, probably with dummy DBpro objects or something....

Good Luck, sound like a good idea if you can get it to work

If it ain't broke.... DONT FIX IT !!!
kaedroho
17
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 8th Oct 2009 12:23 Edited at: 8th Oct 2009 12:31
Physics will still use DBP objects. Physics wont even be done in the build loop anymore. There will be a new function added.

BT MakePhysicsObject terrainid,sectorid,objectid

If sector id is more than 0 it will only make an object for that sector. If sector is set to 0 then it will make an object for the entire terrain. If your using the RTMS these objects will be internally registered and updated when needed.

The rendering will be done to the same DirectX device as DBPro. This means that all the Z buffers, etc will be the same. The only downside of doing this is that Sync must be switched on. And a render terrain function must be called every loop before sync. The rendering will be a little quicker as this engine will be specialised for terrains.

I acctually made a dll yesturday to test if this is acctually possible. Me and Jeffhuys tested it by rendering a cube in DBPro. Then we hid the cube and made my dll render the cube (by accessing the DBPro internals). Heres the results:

DBPro: 4800 FPS
My DLL: 5500 FPS

My dll is higher because DBPro has many features inside its render loop which Terrains don't need. My rendering system only uses the things which Terrains do need.

I predict that version 1.06 is less than a month away now.

KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 8th Oct 2009 20:13 Edited at: 8th Oct 2009 20:13
Quote: "I predict that version 1.06 is less than a month away now."


Outstanding!!!

Login to post a reply

Server time is: 2024-11-23 14:32:35
Your offset time is: 2024-11-23 14:32:35