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
gwheycs62egydws
14
Years of Service
User Offline
Joined: 17th Aug 2009
Location: The World
Posted: 6th Jul 2012 12:26
@kaedroho

ahhh ok

I for one am glad to know ;o)

to move side ways - is to move forward
Since a Strait line gets thin fast
Olby
20
Years of Service
User Offline
Joined: 21st Aug 2003
Location:
Posted: 6th Jul 2012 12:27
Quote: "I've recently got back to work on BlitzTerrain (I've been doing bits and pieces over the past year but now I'm hoping to get back to the way development was before). I've mainly been doing code cleanup for now. I'm getting everything into classes. All is going well so far."


Excellent news! Is it going to be a pure bug fix update or you're aiming to implement the features you mentioned a while ago?


Intel Core2Duo 2.2GHZ, 2GB, GeForce 8600M GT 1280MB, Windows Vista Ultimate SP2, PureBasic 4.61 + DarkGDK 2.0
kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 6th Jul 2012 12:33
Its going to be a bit of both. I won't be adding any big features like streaming or spherical terrains yet. I'll be making some changes that may break peoples code though which is why the next update will be BlitzTerrain 3.0. Those code breaking changes will mostly be things to make it easier to use.

I'm also restructuring the code and removing a few hacks that I added to make some things work (and also caused some bugs!).

gwheycs62egydws
14
Years of Service
User Offline
Joined: 17th Aug 2009
Location: The World
Posted: 6th Jul 2012 12:36
@kaedroho

ya I can see all that would take some time to work out

to move side ways - is to move forward
Since a Strait line gets thin fast
BEAST
11
Years of Service
User Offline
Joined: 11th Jun 2012
Location: the gamecreators.com
Posted: 6th Jul 2012 16:13
no i don't have the matrix utils? how can i get it Brendy

BM
kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 6th Jul 2012 16:36
BEAST
11
Years of Service
User Offline
Joined: 11th Jun 2012
Location: the gamecreators.com
Posted: 6th Jul 2012 17:00
where to add all these Matrix1Utils file. is it in my dark basic/ compiler plugins-user

BM
BEAST
11
Years of Service
User Offline
Joined: 11th Jun 2012
Location: the gamecreators.com
Posted: 6th Jul 2012 17:28
where to plug-in the Matrix1Utils

BM
Duffer
21
Years of Service
User Offline
Joined: 9th Feb 2003
Location: chair
Posted: 6th Jul 2012 18:53
@ Kaedroho,

Great to hear from you again and to see you're working on version 3.

For the dum among us (me), can you explain how v3 would work for someone using it within DBPro? Presumably we will still have a plugin with commands, dll, ini, help?

a long time dabbler with DBC and DBPro with no actual talent but lots of enthusiasm...
kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 6th Jul 2012 19:08 Edited at: 6th Jul 2012 19:10
It will be almost the same but some functions will be removed (as described in an earlier post). The removal of the dependency on DBPro is just an internal thing, it will allow BT to run on its own or in another engine. It will also improve support for DarkGDK (the DarkGDK port is "bodged" with loads of #ifdefs to make it work with GDK).

Pincho Paxton
21
Years of Service
User Offline
Joined: 8th Dec 2002
Location:
Posted: 6th Jul 2012 20:24
Spherical terrains would be ace! I have two projects that can use that.

Duffer
21
Years of Service
User Offline
Joined: 9th Feb 2003
Location: chair
Posted: 7th Jul 2012 11:32
@ Kaedroho,

Good to know. So, basically, you're changing the foundation stones of the plugin (from the ground up) so it is more flexible and can be used by other third party software as well... what's that word? 'extensible'?

I suppose as long as it knits with things like physics and shaders still in DBPro it does not matter - and if it means it is then easier after that to develop it further, great.

a long time dabbler with DBC and DBPro with no actual talent but lots of enthusiasm...
BEAST
11
Years of Service
User Offline
Joined: 11th Jun 2012
Location: the gamecreators.com
Posted: 7th Jul 2012 19:42
how can i fix this problem " Image Dot imgWM0, xPos, zPos, RGB(0, 0, 0, 0) " in dbpro Could not understand command

BM
gwheycs62egydws
14
Years of Service
User Offline
Joined: 17th Aug 2009
Location: The World
Posted: 8th Jul 2012 02:09
@kaedroho

I have only found one dll plugin some got working with DBP ;o)

so now I know ware your going with this

to move side ways - is to move forward
Since a Strait line gets thin fast
kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 8th Jul 2012 13:09
Duffer, I think the word is "portable".

Separating the DBPro bit from the main terrain engine will also greatly simplify the engine. Currently, everything is mixed together.

a simpler engine = easier to code and spot bugs = more stable and fast code

BEAST
11
Years of Service
User Offline
Joined: 11th Jun 2012
Location: the gamecreators.com
Posted: 9th Jul 2012 06:41
Could you help @ kaedroho with the doll plugin

BM
BEAST
11
Years of Service
User Offline
Joined: 11th Jun 2012
Location: the gamecreators.com
Posted: 9th Jul 2012 06:49
Sorry it dll plugin my phone auto correct it

BM
Humanoid
20
Years of Service
User Offline
Joined: 20th Sep 2003
Location: Finland
Posted: 9th Jul 2012 09:00
@kaedroho: okay. I hope that v3 better than 16 bit desktop mode compatible. I hope that will also be new commands. For example, a pick terrain to be completed from the vertex functional x, y, z location. At present, will be used crooked tricks almost the same result. Even self-repair is still there in their own version of that bluegui 16 bit version. corruption icons on the buttons.

kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 9th Jul 2012 12:18 Edited at: 9th Jul 2012 12:37
I'm currently working on modularising BT (which is why the DBPro part will be separated). I'll look into adding new commands like you've said to the collision module.

I'm thinking of making various RAM optimisations too. One of which should allow terrains of up to (an maybe above) 16k x 16k in size. The idea would be that it loads the heightmap into RAM but only creates meshes for parts around the camera. So kind of like streaming but from the RAM instead of the hard drive. This may make creating the streaming commands easier too.

I've got some good ideas for how to do the spherical terrains too. But these 2 features will only be possible after the modularisation is complete.

The main part of the modularisation would be to make the sectors not care about the terrain they are on. The terrain will pass variables and function calls down but the sectors will never access the terrains variables/methods itself. This will make it possible to trick the sectors so they can be used in things like streaming terrain without having to be heavily modified.

smaas
15
Years of Service
User Offline
Joined: 29th Oct 2008
Location: Edam, Netherlands
Posted: 9th Aug 2012 20:46
I have the same problem as CumQuaT. When I use my shader the camera's don't see the terrain. They do see other objects even if a use a shader for them.

Attachments

Login to view attachments
KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 6th Sep 2012 00:01
Kaedroho, glad to see this project still progressing.

While I'm not doing development full time anymore, I have been wanting to dabble with a few projects.

Would the new fixes cure the problem we were having with my Endless Terrain Demo where the seams between terrains didn't line up?

kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 6th Sep 2012 12:00
The changes I'm working on do involve stripping out lots of old code and adding lots of new code in to replace it. Hopefully this will remove many bugs but it will create lots of others. But the new bugs will be easier to solve due to the simpler design of the new code.

As for shader issues, sadly this is something BlitzTerrain has always failed at. I will take a look into that for the BT 3 release.

kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 15th Oct 2012 11:28 Edited at: 15th Oct 2012 11:34
Quick update:
Over the past couple of months what used to be "rewrite parts of BlitzTerrain" has turned into a total rewrite!

Work so far is going quite well. The main reason why I want to rewrite it is because its got very complicated over the years. Theres quite a few little hacks that have caused issues (like the edge lines screwing up for some people).

Heres some goals for BlitzTerrain 3: (many of these are internal changes)
Simpler Internal Design - Allows adding new features easily
No Hacks (or at least as little as possible!)
Automate as much of the code as possible - Write a simple program to generate all the wrapper code, ini files and string table from an XML file. This will make things much more consistent and also easier to add new features. I'd like to do the same for file saving and loading.
Separate the wrapper code - This will allow to make a wrapper for other game engines. It will also improve GDK support as it can have its very own wrapper.
Better error handling - Add ability to silence error windows and handle the errors in functions like "BT GetError()". Also provide more info like line numbers.
Better GDK support - GDK has always been a bit behind the DBPro version. I hope with BT 3, because of the wrapper changes, we can have great GDK and GDK 2 support.
Separate data sources - Allow adding new data sources to get heightmap data. Some examples include, Heightmap, File, RAW, Network, etc. This will also allow streaming!
Separate rendering code - Make rendering a separate module to bolt on the side of BlitzTerrain, this makes the central part less complicated and also allows it to render for OpenGL.
Good Documentation - Current documentation Isn't very good and there are no examples. I hope to create web based documentation for BlitzTerrain 3.0 and include tutorials and principles pages to help programmers understand what BT is doing under the hood.
Look into improving shader support - Many complaints about BT2 due to its rubbish support for shaders
Make Terrains DBPro objects - Much less complexity for programmers
Plugins - Create a more open plugin API and try to implement as many features as possible as plugins. This should be possible for Exclusion, Quad Reduction, Quad Rotation, Smoothing and RTTMS (which is already a plugin)
Better Collision Support - The data for BT objects is kept separate from the rest of DBPro. I will look in to a better way to get this data to collision systems. Add come collision commands like raycast/spherecast. These will be much faster than other collision plugins as they will be optimised for terrains.

I've done most of the core code already. I can't give a time when it will be done though (I've not been great at sticking to deadlines in the past).

Duffer
21
Years of Service
User Offline
Joined: 9th Feb 2003
Location: chair
Posted: 15th Oct 2012 23:52
@ kaedroho,

Excellent news! Thanks for the update - great to see you are still very much taking this further. Looking forward to the next update too...

a long time dabbler with DBC and DBPro with no actual talent but lots of enthusiasm...
Matty H
15
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 17th Oct 2012 21:50 Edited at: 17th Oct 2012 21:51
Hi kaedroho, I have a program that automatically creates documentation as html files. It creates a page that lists(links) all the commands too, I also recently added the ability to add sub headings.

You may want to write your own for complete control, but let me know if you are interested, you can have the source too.

kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 19th Oct 2012 01:53 Edited at: 19th Oct 2012 02:04
Thanks for the offer. I've got an idea for how I'm going to create the help files. Its using the same method I'm using to create all the wrapper functions for DBPro.

I'm developing the core of BT in C++ classes. For the DBPro wrapper part, I've created an XML file that describes every function and which class/function they point to inside BT. I run this XML file through a python script to generate all the functions in C++, string table, keywords and help files in one go. The generated code contains all the stuff needed for validation, data conversion and error handling.

Its a bit of a mad idea but seems to be working so far. The idea is to let me maintain multiple wrappers for different engines and just have a python script for each one. Write code once, and all the wrappers and help files update themselves. Its also great for more consistent code.

I'm thinking of creating a "DBPro Plugin Creator" which uses this technique as it saves a lot of time. It got the idea of this technique because this is how the Wayland display protocol is written.


Heres an example:



This can also allow for some more cool stuff. For example, all functions I've written that uses XYZ I've made it produce a function for each X, Y or Z. So just tell it to create:

BT SetTerrainScale Terrain, X, Y, Z

It will automatically create these as well:

BT SetTerrainScaleX Terrain, X
BT SetTerrainScaleY Terrain, Y
BT SetTerrainScaleZ Terrain, Z

Another thing is that theres 2 ways to address a sector on a terrain. Through its ID or through its X/Y. I've let the python script know about this and for every function that takes a Sector as an argument it produces one copy for each way of addressing the sector.



Bit of a long post... But just thought you might like to know about that idea. Much of the above is still theory and I've only got the basics working for now. But I can imagine something like that saving a lot of time for plugin developers like yourself though.

Matty H
15
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 19th Oct 2012 12:40 Edited at: 19th Oct 2012 12:41
Cool. Our systems are not too different, I tend to think keeping the documentation inside the source is a good idea, any changes to the source and you can easily update the documentation as they are next to each other.

Quote: "/*
* @description This command will create a linear kernel for use with a force field, this structure holds data which will determine how, and by how much, the force field will affect objects at different positions in the force field.
* @param ID - ID number you wish to assign to this kernel.
* @param constantVector3ID - The constant part of force field function. For a force field with cartesian coordinate space, this would affect the CORE direction objects would move in the force field.
* @param falloffLinearVector3ID - Affects how strong the force field is relative to its centre with linear falloff.
* @param falloffQuadraticVector3ID - Affects how strong the force field is relative to its centre with quadratic falloff.
* @param noiseVector3ID - Adds the given amount of randomness to how objects are affected along each axis.
* @dbpro DYN MAKE FF LINEAR KERNEL
* @category CONSTRUCTION
*/
bool dynMakeFFLinearKernel(int ID, int constantVector3ID, int falloffLinearVector3ID, int falloffQuadraticVector3ID, int noiseVector3ID){
...
...
}"


I like the idea of automatic generation of string tables, I looked into it but did not understand the patterns and could not find a guide

A plug-in creator would be awesome, and writing 'get' and 'set' functions is a real pain so that's a great idea what you have there.

Duffer
21
Years of Service
User Offline
Joined: 9th Feb 2003
Location: chair
Posted: 1st Nov 2012 00:40
@ Kaedroho,

Hi there.

Just posting to see how the Blitzworks Terrain v2 is coming along....?

p.s. intrigued by the plugins creator too...

a long time dabbler with DBC and DBPro with no actual talent but lots of enthusiasm...
kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 1st Nov 2012 02:38
BT v3 is coming along. I'm going part time in a couple of weeks so I can focus on my studies and programming projects more.

So expect more frequent posts from me then!

CumQuaT
AGK Master
13
Years of Service
User Offline
Joined: 28th Apr 2010
Location: Tasmania, Australia
Posted: 1st Nov 2012 06:06
Huzzah!


MrValentine
AGK Backer
13
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 1st Nov 2012 06:13
wow, What did I miss? V3... I was not even aware of V2... fill me in please

kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 1st Nov 2012 13:23
I started work on V1 of BlitzTerrain (called UberTerrain back then) in the first half of 2008. It was pretty slow so around summer 2009 I decided to rewrite the whole thing from scratch. Thats the current V2.

Last year I started another rewrite which I'm calling "V3". Work has been a lot slower than before because I now have a full time job and I'm doing a degree in computing at the same time...

The reason for this is V2 is a bit monolithic. I'm going for a simpler and more modular design with V3. This makes it easier to add new features and reduce the chance on introducing bugs.

I will implement streaming and spherical terrains as modules which have both been promised since 2009.

Another thing is that it's too tied in to DBPro. I'd like to create BTv3 in 2 parts. The core and the wrapper. The core part will be released standalone which people can import into other engines. The wrapper has all the DBPro/GDK/GDK2.0 specific stuff.

MrValentine
AGK Backer
13
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 1st Nov 2012 13:43
Quote: "I will implement streaming and spherical terrains as modules which have both been promised since 2009."


Get this done, and you got yourself another sale...

Btw is there any video of how to use and work with BliTer?

kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 1st Nov 2012 20:05
Another thing I have planned for BT3 is separation of data sources from the core. The core part will think in "regions" which will be like sub terrains within terrains, these can be dynamically loaded and changed at runtime. Streaming will simply be implemented as a new data source which can load terrain regions individually. Another cool thing about this is theres nothing in the way of creating new data sources which generate terrain on the fly (so basically, infinite terrain). Even streaming terrain over a network should be possible!

Quote: "Btw is there any video of how to use and work with BliTer?"



I haven't made any video tutorials yet but there are docs and examples. If you have any problems or need help getting started, feel free to post here or send me an email.

One of the the most important improvements I'm making with BT3 will be better documentation and more tutorials and examples.

MrValentine
AGK Backer
13
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 1st Nov 2012 20:39
Well, one primary thing holding me back from getting BT, is not having a clear picture of it, by that I mean I think I had a demo of sorts or something and I may have had the wrong impression...

I shall stick around and hope for more detail as I can currently no longer use 3DWS as it does not like function in Windows 8... [at present]

Duffer
21
Years of Service
User Offline
Joined: 9th Feb 2003
Location: chair
Posted: 1st Nov 2012 21:42 Edited at: 1st Nov 2012 21:42
@ Kaedroho,

Not much but my time is yours if you want someone to proof read your new help documents (from the perspective of a duffer like me....)

a long time dabbler with DBC and DBPro with no actual talent but lots of enthusiasm...
kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 10th Nov 2012 15:59
Duffer, Thanks!

Heres a little info about some of the key changes for BT3.

In BT2 a terrain was a set fixed size. Terrains contained a fixed number of LOD Levels and they contained a fixed number of sectors. Sectors cannot change size.

BT3 is quite different...

In BT3 a terrain is made up of "regions". Regions are 256x256 and can be dynamically loaded / deleted on the fly allowing streaming to work. They can also be curved so they can go on the side of a planet.

Regions just contain the height data, there is no sector data below that. LOD is applied to each region on the fly. This makes BT much better on RAM.

The other advantage is that you don't have to build a terrain. You literally, just do "BT CreateTerrain ObjectID" and it will instantly start drawing a blank terrain and it won't build anything. You can then bind a data source to it to give it some height. You can easily change the data source at anytime and your terrain will update automatically!

Also, because all vertices will be in one buffer. The real time modification functions will be much faster.

A vertex shader will be required to use BT3 (this is to reduce RAM use age as X and Z coordinates for each point can be calculated in a VS). But if lots of people object to that, I might add a CPU fallback. The CPU fallback will take up lots of development time to create so I'll only do it if it was really needed. Just about everyone has a GPU capable of processing vertex shaders now so I don't think this is going to be a problem.

Another thing is the geometry processing part - The bit that turns points into triangles, also does exclusion, quad rotation, etc - Can be wrapped in an OpenCL program. This means that you may be able to send all vertices to the GPU and get the GPU to process them for extremely fast loading times. This feature isn't official yet though as I'm not experienced in OpenCL. But I will be looking in to this! I may also use OpenCL for the terrain modification commands.

Last thing, the core of BT3 will be open source and will work with OpenGL ES 2.0. It will be cross platform. It will be released under MIT license.

Duffer
21
Years of Service
User Offline
Joined: 9th Feb 2003
Location: chair
Posted: 10th Nov 2012 16:31
@ Kaedroho,

That all sounds great. What about textures with BT3? How are they applied / changed?

What is the philosophy for loading in and saving out terrains (in components now? right?)?

a long time dabbler with DBC and DBPro with no actual talent but lots of enthusiasm...
kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 10th Nov 2012 16:57 Edited at: 10th Nov 2012 17:22
Textures will be from DBPro images. When the terrain is rendered, the system will go in to DBPro and look for the Direct3D handle for the texture and apply it to the terrain.

As for loading and saving. They will both be done with standard formats. Theres not a lot of point in creating a new one when things are built on the fly!

I will create a simple image format which creates each region in its own image. Then stitches these images together. This would improve the speed of individual region loading. As only part of the image file will have to be loaded to get the region out.

I will create functions for saving out terrains into both the above format and standard image formats (I'm thinking, BMP, RAW and PNG).


Just as an example, heres how I hope to have terrains created:



That will load and render that terrain! Much simpler than before. You can create blank terrains but by default they will be infinite (streaming will be automatic). Theres a command called BT SetTerrainBounds which will limit the size of the terrain.

kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 16th Nov 2012 13:45 Edited at: 16th Nov 2012 15:40
Terrain Formats

Heres some info on the formats you will be able to use for Blitzwerks Terrain

Heightmaps
Unlike BT2, these will be loaded by the terrain engine using the BT SetTerrainSource command
Supported formats will be: BMP, PNG, RAW and TRAW
TRAW is similar to RAW. It stands for Tiled RAW. The difference is that the points are stored as 256x256 tiles instead of a massive image. This allows faster loading of individual regions
The RAW format will be unsigned 16 bit integers

DBPro
There will also be support for loading from DBPro Images and DBPro Memblocks
BT SetTerrainSourceImage
BT SetTerrainSourceMemblock
Both will be seen as a regular heightmap. The memblock will have to store its data in RAW format
Terrains created from images will be read only but terrains made from memblocks will allow write back access. This means that when the RTTMS commands are used, they will be able to write back to the original memblock.

Multiple heightmaps
For large terrains, you can split your heightmap in to multiple heightmaps. Each region has its own heightmap. These can be dynamically streamed on the fly
All formats for regular heightmaps will be supported
To load a heightmap in this way, use the BT SetTerrainSource command:
BT SetTerrainSource "terrain/r-${X}-${Y}.png"
You may need to use BT SetTerrainBounds to make sure that it only loads regions that exist (not doing this won't cause a crash, it will just make BT create blank regions for the areas it couldnt load).
You can also put the above info in a terrain description file (explained below)

Terrain Description File
This is a simple XML formatted file for loading some configuration for a terrain. The configuration includes things like data source, bounds, scale, etc.

It looks a little bit like this:


Note: for this example you wouldnt need to set the bounds of the terrain as they will default to the heightmap size.


HTTP
All the above can also come from a HTTP (web) server. Simply append http:// to the beginning and it will enable this feature.

BT SetTerrainSource "http://www.helloworld.com/myterrain.png"

The terrain will be downloaded and displayed! The same goes for streamed terrains and all above formats are supported.


HTTPS/FTP (possible future feature)
These won't be in the initial release, but they may appear in the future depending on demand.

BTs own file format (possible future feature)
I have ideas for a file format that might be quite handy. The format will store large amounts of height data as regions. The data will be indexed for fast access. The indexing will also allow the data to be added at any time. This also won't be in the initial release but I will be looking in to it.


Textures and Environment maps will be very similar. Let me know what you think of the above.


Another quick comment: I will be looking into AppGameKit support. BT will support DirectX 9 and OpenGL ES 2.0 for rendering. I haven't looked into this or spoken to Lee about weather this is acctually possible. But if it is possible, I'll add AppGameKit support. The AppGameKit support will likely be native only.

Duffer
21
Years of Service
User Offline
Joined: 9th Feb 2003
Location: chair
Posted: 16th Nov 2012 17:00
@ Kaedroho,

Cool beans! [Being dumb] I will probably need the terrain streaming (and coding thereof) explained in monosyllabic terms. I almost understand....

I presume if you had a 3 by 3 grid and you were moving up you could load in a new top grid and shunt the others back (in terms of the tiles of data sources)?

a long time dabbler with DBC and DBPro with no actual talent but lots of enthusiasm...
kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 16th Nov 2012 17:10
To do streamed terrains, you just need to split your heightmap into regions and number them by where they are:

region-0-0.png
region-0-1.png
region-123-0.png
etc

Each region is a 256x256 heightmap.

You then tell BT what the file names of all these are
BT SetTerrainSource "region-${X}-${Y}.png"

The $(X) and $(Y) tells BT where to get the location of the region.
When BT wants region 0,0. It will look at the file name and replace the $(X) and $(Y) with the location of the region.

You can set what happens when a region cannot be loaded. You can make it fail silently leaving a hole in your terrain. You can make it use a blank region instead (which is good for editors). Or you can make it crash .

kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 16th Nov 2012 17:22 Edited at: 16th Nov 2012 17:23
A little info on environment mapping:
In BT3, I'm hoping to have better use of environment mapping.

Environment mapping is simply a way to set what environment is at each part of a terrain. It lets you set which parts are for example, a beach and which parts are grass, snow, etc. You can use it for applying footstep sounds.

I hope to allow textures and detailmaps to be applied to certain environments. Also, I'd like to add some way of painting the terrains base texture based on the environment map (so you can say, make all the grass green and give it a grassy detailmap).

I also hope to add functions to allow you to easily create environments. For example, imagine if you can just say "everything under 100 is underwater". And "everything on a steep slope is rocky (like a cliff)". etc.

Also I'd like to merge Exclusion with Environment maps. So basically, you use the environment mapping features to say what must be excluded.

Duffer
21
Years of Service
User Offline
Joined: 9th Feb 2003
Location: chair
Posted: 16th Nov 2012 17:36 Edited at: 16th Nov 2012 17:39
@ Kaedroho,

Ah. I see (re streaming). Simpler than I thought. Will that loading in of files make your journey across the terrain 'jerky' or are we talking multi threading or some other neat mechanism here?

p.s. I really like the idea of the intelligent detail maps based on environment maps... would make things v much easier...

a long time dabbler with DBC and DBPro with no actual talent but lots of enthusiasm...
kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 16th Nov 2012 20:25
The loading will be multithreaded. The regions are only 256x256 so it doesn't take long to load them anyway.

As I mentioned earlier, I will be looking into OpenCL. This will allow the conversion of height data into mesh data to be accelerated by the GPU.

Chris Tate
DBPro Master
15
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 16th Nov 2012 21:27
So, when roughly do you think you'll have something ready to test? I was just about to buy the full version of your current system. How much will this cost?

I like the HTTP idea; something I could do with.

Duffer
21
Years of Service
User Offline
Joined: 9th Feb 2003
Location: chair
Posted: 16th Nov 2012 22:26
@ Kaedroho,

- will BT3 have LOD and Quadtree?

- how easy will RTTMM be?

p.s. as I say, happy to help with the documentation, proof read, give you the dim user perspective...

a long time dabbler with DBC and DBPro with no actual talent but lots of enthusiasm...
kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 17th Nov 2012 13:20 Edited at: 17th Nov 2012 13:21
Chris Tate,

Expect something in the first half of 2013. It will most likely cost the same as BT2, £25.

Duffer,

Yes, it will use both quadtrees and LOD.

I haven't planned out the RTTMS commands yet. They will probably be very similar to the current ones. But there will be more!

Thanks for your offer, I'll send you an email when I get a draft done!

Kezzla
15
Years of Service
User Offline
Joined: 21st Aug 2008
Location: Where beer does flow and men chunder
Posted: 18th Nov 2012 06:36 Edited at: 18th Nov 2012 06:48
this all sounds awesome. edit:didnt see last page/edit I cant wait to play with it.

kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 20th Nov 2012 01:07
First renders from OpenTerrain (which will be the core of BT3) made today. LOD system using Quadtrees up and running!

Login to post a reply

Server time is: 2024-04-23 14:11:21
Your offset time is: 2024-04-23 14:11:21