Raiders of the lost Brushes

Blitz3D Forums/Blitz3D Programming/Raiders of the lost Brushes

jfk EO-11110(Posted 2007) [#1]
I still have a problem with saving meshes using correct texture flags, blendmode etc.

The basement for this is a modified version of the SaveB3D code form the archives. In my app I need to AddMesh multiple meshes together to one mesh, then I save this multisurface mesh.

While it is possible to store each loaded meshes properties (flags etc.) by using the DumpB3D example from the b3dfile_utils.zip, I am losing control over them when I use commands like GetSurfaceBrush. This will create a new brush that is identic with the original brush, but actually is a new brush with a new handle.

Now, the only way to identify a brush would be to track down its texture filename(s). Problem: there may be brushes that are using the same texture, but diffrent flags etc. So this method is not save.

Do you have an idea on how to identify a brush, to compare it against a list of brushes, where in the list I got all properties stored, but Blitz's native commands to determine Brush properties (of a brush created using GetSurfaceBrush) are very limited (see online manual, search for "brush"). Any ideas? thanks!

EDIT
Ok right now the best solution I got is: With every loaded mesh its properties are collected in a global brushes list, using the DumpB3D example. Then when I have to identify un unknown, cloned brush, I will use the Properties hack functions, as good as it gets: I can't use them to determine the texture flags (that's the reason why I don't use them in the first place). So I wil compare texture names, fx, blendmode, tex scale, position and rotation, basicly everything but the flags that cannot be determined by the hack method (peeking offset etc)

If all these things are the same then I may assume we have identified the brush in the list of known loaded brushes. Unfort. this also means if only the flags are diffrent (and if the texture name is the same, then the flags may indeed be the only thing that is diffrent) then it won't be recognized correctly.
So, basicly I'm still searching for a real solution.


Ricky Smith(Posted 2007) [#2]
Good luck jfk - this would be very useful !


jfk EO-11110(Posted 2007) [#3]
ouch - you were my last hope...

Currently I have no plan. The comparing method is not safe and complex, probably bug-sensitive and especially not future compilerversions proof.

I just can't believe there's no way, no trick or cheat.


Ricky Smith(Posted 2007) [#4]
jfk - I'm sure its possible - I would use the global list of all loaded brushes method and compare texture filenames.
Using a naming convention for the texture filenames when they are used with different flags may help ?


jfk EO-11110(Posted 2007) [#5]
I'm trying to find a solution for this since a few days now. I want to cover most possible situations. It's easly possible that a mesh is using the same texture twice, with diffrent flags. Using a naming converntion in the filenames woud force me/the user to have the texture twice on the harddrive. I'd also like to make it in a way that allows to use any mesh file as long as blitz can load it.

The problem with the flags hack is: when the bit value 4 is set, the bits 1 and 2 are ignored:

set / peeked
0:0
1:1
2:2
3:3
4:7
5:7
6:7
7:7
8:8
9:9
10:10
11:11
12:15
13:15
14:15
15:15

and so on.

There is some action at other adresses too, in relation to the tex flags, but none of them allows to see if %111 is 4,5,6 or 7.

I am currently thinking about to use Tomspeeds MemoryLib.dll that has a GetTextureFlags decls function. Not sure tho if this still works. I would also like a solution that works without external dlls. Noless, this may be the only way out:
http://tomspeed.com/memorylib/

well, basicly I am fighting against two bits here :) Programming games can be martial sometimes :/


jfk EO-11110(Posted 2007) [#6]
Update:
I just tried the latest version of TomSpeeds MemoryLib.dll. It seems he had to release a new version for Blitz3d 1.98. Actually, this one works, there's only one problem left:

Unlike in the old version you have to use the texturebuffer handle as the parameter of GetTextureFlags(). This means, since DDS textures will return zero with TextureBuffer(), they cannot be used with Tomspeeds DLL.
Funny, since it was Toms DDS code that was added to Blitz3D.
Not funny: I really wanted to use DDS a lot! Yes, I could use other masked textures, and then patch the final b3d files. But I hate this patchwork artpath where you have to remember to do this and that and that...

Some more infos:

When a texture is created using CreateTexture then the flag 1 is set automaticly. When a texture is loaded then the flag 9 (8+1) is set automaticly. This discrepancy doesn't make sense to me, however. When ClearTexture is used before then the bit value 8 is not set automaticly.

When the mask flag 4 is used, the bit value 1 is forced automaticly. This means, setting the flag to 4 will automaticly turn it into 5. For some reason it also seems you cannot set bit value 2 and 4 at the same time, or, bit value 2 (alpha) is ignored automaticly as soon as value 4 (mask) is set. So the mask flag priority rules over the alpha flag.

Ah, no DDS. What an odysse!


LAB[au](Posted 2007) [#7]
thanks for the report, really valuable info in there.


D4NM4N(Posted 2007) [#8]
Hi JFK, i dont know if it can be adapted for your needs, its set up for a group of terrain blocks as one mesh, but that could be adapted to recursively store any mesh (in theory).

There is a surface recording system and if a texture has been used once already it cross references its ID. Or at least should do :P

in the record brushes bit, you would still need to find a way of reading the getsurfacebrushes FX (at the moment im setting it manually from TEDs internal knowlage of what i want, but if you store it there in \bfx it should still be able to cross reference the same texs

Mabe the system i use for recording brushes may help you, or not...




jfk EO-11110(Posted 2007) [#9]
I'll try this, thank you!


jfk EO-11110(Posted 2007) [#10]
Ok, thanks for all your help. For all those who need a solution for the same problem, here's how I fixed it for now:

All properties can be determined using tomspeeds MemoryLib.DLL (mentioned above), with the exception of:

Blitz's internal functions
GetSurfaceBrush
GetBrushTexture
TextureName

as well as

To obtain texture x scaling and y scaling and the coordSet flag. For these 3 functions use the old hacks published here:
http://www.blitzbasic.com/Community/posts.php?topic=66397
GetBrushTextureCoords
GetBrushTextureScaleU
GetBrushTextureScaleV


Note: although Tomspeed's dll will return the TexFlags, the bit $10000 (65536) does not reflect the CoordsSet as it is stored in the B3D file! Therefor you need to use the hack GetBrushTextureCoords(tex)

Now, with this patchwork of internal functions, external functions and quickndirty hacks, all informations to save a (static) mesh with all visual settings (excluding cubemapping) can be determined. Future compiler version compatibility not guaranted.

Unfort. there may be a memory leak caused by lost brush handles. Noless, a tool can be powerfull, even if it has to be restarted from time to time.

EDIT Additional Note:

when using GetBrushTexture for the 8 possible textures of a brush, it will return numbers other than zero, even if there is no texture on a certain layer. Currently the only way to determine if a returned number is a valid texture handle is to use:

if TextureName$(tex(i))<>"" then

This does of course exclude the usage of Textures that have been created using CreateTexture (I have no idea on how to handle them right now)

Note, it seems TextureName will return the texture name as it was used in the LoadMesh function, regardless if the file was found. So if the file wasn't found, it will still return a TextureName() other than "", but the texture handle will be invalid! To check this out you need to use

Is there a TextureName? yes, layer seems to be used.
Does a file named Name exist? Yes, assume the texture was loaded.
Now you may access TextureBuffer() without to worry too much. If it returns zero, it seems to be a DDS texture, this can be doublechecked by testing the filename extension (".DDS").

After all:
GetBrushTexture(brush,index) that won't return zero for unused layers may be considered a bug.