DeleD Community Edition

[Il Buzzo]

Hi All,
Updated DBO Exporter to version 1.0 RC3 [139KB]

In this version I've just solved strange behaviours described in readme.txt and I've unlocked scaling edit controls (you couldn't re-enter '.' char once deleted, you needed to paste, now it's fixed).
So this is going to be the final release unless other bugs will be found
As usual you can download new version from:
[href]http://www.ilbuzzo.net/downloads/DBOExporter.zip[/href]
Bye

[hpesoj]

Umm, well, the plugin seems to be VERY tempermental after further testing. I've tested on the premade maps, and they seem to work once lightmapped (although I haven't tried them all). But building a level, I find that the object exported loads and doesn't load depending on how many objects/materials you have in the scene, and if it's lightmapped or not. Here are a few examples....

1 Cube - Works
1 Cube Lightmapped - Doesnt work
2 Cubes - Doesn't work
2 Cubes Lightmapped - Works
3 Cubes - Works
3 Cubes Lightmapped - Works
4 Cubes - Doesn't work
4 Cubes Lightmapped - Works
5 Cubes - Works
5 Cubes Lightmapped - Works

5 Cubes, 2 Materials - Works
5 Cubes, 2 Materials Lightmapped - Works
5 Cubes, 3 Materials - Doesn't work
5 Cubes, 3 Materials (or more as far as my testing goes), Lightmapped - Doesn't work

Various levels of mine don't work when either lightmapped, or un-lightmapped. They still don't seem to be compatable with Newton, and I've tried a level lightmapped in Giles, and it works fine, so it's not an internal problem with DBPro, lightmaps and Newton.

I'm not sure what's going on, but to be honest, I'm finding it very difficult to get a fully working level exported .

[Il Buzzo]

Hi hpesoj,
Have you tried DBOExporter Release Candidate 3?
I've solved cube exporting trouble, for your troubles I can say:
1 Cube - Works
1 Cube Ligtmapped - Works since RC3
As stated in ReadMe.txt all levels work when they are triangulated, so if you triangulate your meshes (centroid is better) you'll solve all your troubles.
Note that 5 cubes work with 1,2,3 or more materials, remember that if you have troubles with levels generally is just a complex object with one polygon with too much faces, or a user defined polygon, so in all scenes tried by me the problem is simply solved by triangulating.
Some troubles could be due to the fact that some values in DBO are not written by DBOExporter cause are unused but DBPro in some situations doesn't work without or is unable to set them.
So the next thing I'm doing is adding these values but this way you'll obtain a larger dbo.
Well, I've not tried Newton yet with DeleD levels but I think that you can look at walaber's forum to this thread and look at walaber's answer:
http://walaber.proboards23.com/index.cgi?board=newtdiscuss&action=display&num=1113723796&start=
Well, remember that this plugin is just to use dbo with update 5.8 or you'll get more errors than normal.
Anyway I'm trying to correct all so please be patient.
Bye

[Il Buzzo]

Hi All,
This is really the final release candidate, I've just released the release candidate 4 that fixes all bugs encountered by me in scene loading, with bigger objects too.
Now really each scene is loaded correctly. You can download DBOExporter RC4 [141KB]:

as usual from my site:
http://www.ilbuzzo.net/downloads/DBOExporter.zip
Bye
If you encounter other problems, please let me know and I'll solve, or this will become the final release.
@hpesoj
Try this release, it has loaded each scene (lightmapped and not), scenes that give problems before too.

[granada]

The work goes on,& on nice one

dave
_________________
AMD Phenom(tm)IIx6 1090t Processor 3.20 GHS
8.00 GB memory
Windows 7 64 bit
Nvida Geforce GTX 580

[hpesoj]

Ok, sorry, it is working pretty much fine with DBPro . But Newton was causing the problems. Looking at a simple lightmapped cube file (with one material), not that I'd rely on me to be able to decode the DBO format, I found this...

I scan in the first sibling frame, and read a code 17, what is this for? Then I read the matrix and mesh (mesh block size = 2396) fine (dunno where the name went, I guess you don't really need it). But after the mesh, the next code and size I read are completely off the wall. Obviously where no data has been written. You may want to have a look at that :S. Then my code gets stuck in a loop because the codes never reach 0.

[Il Buzzo]

Hi hpesoj,
Have you tried RC4, is far more precise than other releases.
Code 17 is non existent, there is no way it could be written unless it's a size of a string or some other things.
After the mesh you obtain some other codes, in example animation 2, and user defined 406 that are not used at the moment.
Anyway to make a test you can try this thing, load a DeleD exported cube with DBPro and resave it with DBPro, see what's happening rescanning it!!!
You'll notice that DBPro returns you some wrong size values in resaved file that bring you to some errors (in some frames that you know DBPro must give you 4 it gives 6 etc...).
You must remember that DBO frames has a structure like this:

[hpesoj]

Hey Il Buzzo,

Yeah I have tried the latest build, it works with DBPro, but not with Newton, Newton was what was causing all the problems. I have found that you are not writing a file size variable to the sibling frame. Is there any reason for this? Isn't the format like so (only taking into account syblings)...

root frame code
root frame size
......
sybling1 code
sybling1 size
name
........
sybling2 code
sybling2 size
name
.......
endsybling2
endsybling1
.......

I am trying to read the block size after EVERY code that I read in. Is this correct?

[Il Buzzo]

Hi hpesoj,
this is the question !!
It's not well documented in DBO format but sybling1 contains sybling2 and sybling3, also if they are on the same logical level, so let's say that each sybling real data is 200 in size than if sybling3 is (just as hypothesys) 200 in size, then sybling2 size is syblyng3 size + 200, and sybling 1 size is sybling 2 size +200, so in the end you'll have:
sybling1 size=600
sybling2 size=400
sybling3 size=200
this means that sybling1 contains sybling2 that contains sybling3 etc...., this is the reason I've lost a little time in looking at DBO generated by DBPro to understand....

The fact that you read codesize after each block is correct, but then you must jump a number of codesize bytes to read the next code and codesize, unless you're reading a root frame or sybling or child code, or mesh or texture code.
The main scheme is the following:

Read dwCode
Read dwCodeSize
if(dwCode is not frame root or child etc...) read (data) a number of dwCodeSize bytes
else continue reading until end of file

You should give a look to DBO file format guide to know what values are followed by data and what are just followed by other subblocks.
I hope to have been clear enough but DBO is not so clear in my opinion.
If you're not convinced by this explanation you can prove yourself this way (this is how I did it):
create 3 triangles in DBPro, then create a mesh from the second and the third. At this point add two limbs (the created meshes) to the first triangle, save as DBO in DBPro and give a look to it.
Bye

[hpesoj]

If I export 3 triangles in one object, I only get the first triangle out.

I have got the idea with the DBO format. My algorithm is like this (I'll write crap C++ psuedo, even though I'm using Delphi)...

[Il Buzzo]

Hi hpesoj,
OK, your code seems correct, this is the right way, but remember that DBPro introduce some values in the wrong position and alterate some size values.
Bye

[Il Buzzo]

Hi All,
Now just a question for the community, as DavidOC on DBPro forums let me notice for a better organization it will be usefull to change lightmaps name and select a subfolder for textures exporting.
So now it's your turn to decide, if you want this solution, let me know and I'll change or if you have other ideas, please let me know.
If the trouble of collision will be fixed with a whole mesh (no textured) I could also add to DBO Exporter a flag to export directly a collision.dbo that has only geometry data, no textures etc....
But I need to do some more testing with Newton to ensure.
Bye

[hpesoj]

More options would be handy. Sub-directories for textures would be good. If merging the mesh would fix the Newton problem, it'd be good. I can't think of any other options at the moment.

Good news is I fixed my DBO thingy . It turned out it was a problem with my reading code. Your objects now load flawlessly. I can't see what could be wrong with them :S. Apart from, the root frame doesn't have a mesh, is this for a reason?

[Il Buzzo]

Hi hpesoj,
Let's go with order, first of all root frame hasn't a mesh as choice for DBO Exporter better work.
It's just like you have a dummy object with some syblings....

I fixed Newton trouble this way, look at this before:

what a mess, so it's due to the fact that once lightmapped some parts of an object could be introduced in another meshbuffer.... at this point I've had an idea, so I've saved a version of DBO file not lightmapped (I've called it room_col.dbo), then I've lightmapped the scene and have exported (I've called this one room.dbo) at this point I've generated Newton collision on not lightmapped level (room_col.dbo) and added collision to the lightmapped one (room.dbo), to obtain:

I've used Newton FPS example without door and just modiphyng the code this way:

[hpesoj]

Nice one .