TBGL-Ideas

[ReneMiner]

I still have some wishes to improve TBGL-Entity-System - especially when it comes to fast-loading data directly to entity/display-list.

A dream of sweet cream would be, if there were a native Entity-File-Format that supports both: vertex-colors and materials. So OBJ-format is out of question because does not support vertex-colors - perhaps M15 could be improved by adding some extra material-file - similar as OBJ has - wich holds Material-Data for the single layers - or even better would be some new, simple format that will be read in alike GBufferDefineFromArray from file to some Displaylist-Slot or Entity.

However, the Entity-System of my dreams would do a couple of things:

- manage a Textures-Pool ( maybe occupy slots 1 to 768 ) so every texture gets just loaded once,
- Textures be part of Material (already possible) but mandatory for Entities loaded/saved the way below,
- TBGL_EntityBindMaterial-functionality - or call it TBGL_EntitySetMaterial - whatever...
- support PNG-Format also - to have one compressed that allows alpha
( I know that needs Windows somewhat above Win95 but I think a Win95-PC never would have the needed graphics hardware to run Entities anyway)



this just how I imagine to write data:



Header
' -----------
numTextures
Texture() ' means this is array of numTextures elements with following properties:
Filename
AnisoLevel
Filtering
TranspColor
' if numTextures > 1 then here would follow again Filename, AnisoLevel, Filtering, TranspColor
' -----------
numMaterials
Material()
Ambient R, G, B, A
Diffuse R, G, B, A
Emissive R, G, B, A
Specular R, G, B, A
SpecExp E
TextureIndex ' points to a Texture() above or 0 if none
BlendFunc
AlphaFunc
' -----------

ParentEntity
MaterialID ' points to a Material() above
Rotate X, Y, Z
Scale X, Y, Z
Translate X, Y, Z

PolyType ' TBGL_BeginPoly-Equates
VertexType ' see Vertex-Format-Equates below - somehow needs a way to specify this in advance

numVertices
Vertex()
X, Y, Z [, nX, nY, nZ][,tU, tV][, R, G, B[, A]]

numChildren
ChildEntity()
MaterialID
Rotate X, Y, Z
Scale X, Y, Z
Translate X, Y, Z

PolyType
VertexType

numVertices
Vertex()
X, Y, Z [, nX, nY, nZ][, tU, tV][, R, G, B[, A]]
numChildren
ChildEntity() '- here would follow a child of first child if one
'...
ChildEntity() '- while this is second child of parent-entity

'...EOF somewhere here
' ----------------------------------------


' Vertex-Format-Equates:

%Vertex_hasPosition = 0 ' X, Y, Z are always available
%Vertex_hasNormals = 1 ' X, Y, Z, nX, nY, nZ
%Vertex_hasTexcoords = 2 ' X, Y, Z, tU, tV
%Vertex_hasNormalTex = 3 ' X, Y, Z, nX, nY, nZ, tU, tV
%Vertex_hasColor = 4 ' X, Y, Z, R, G, B
%Vertex_hasNormalColor = 5 ' X, Y, Z, nX, nY, nZ, R, G, B
%Vertex_hasTexColor = 6 ' X, Y, Z, tU, tV, R, G, B
%Vertex_hasTexNormalColor = 7 ' X, Y, Z, nX, nY, nZ, tU, tV, R, G, B
%Vertex_hasAlpha = 8 ' X, Y, Z, R, G, B, A
%Vertex_hasNormalAlpha = 9 ' X, Y, Z, nX, nY, nZ, R, G, B, A
%Vertex_hasTexAlpha = 10 ' X, Y, Z, tU, tV, R, G, B, A
%Vertex_hasNormalTexAlpha = 11 ' X, Y, Z, nX, nY, nZ, tU, tV, R, G, B, A




Edit: this way could just return top-level-parent-ID on load
Helpful could be using Entity-Name-Property where names get composed on load like ParentName+ChildNames alike "RobotsGroin_Torso_LeftArm_Hand_Thumb" and some function that lists Children-IDs or vice versa: retrieve EntityID from Scene+Name-parameters

[Petr Schreiber]

Hi Rene,

thanks for your deep thought suggestions.

Regarding file formats - I think the M15 file format is slowly getting obsolete, I designed it at high school and it looks like that. What I like about specific format that we can create validated exporters, which work around issues of imported formats. Have a look at OBJ - simple ASCII format, yet the OBJ2M15 tool contains 5 checks to fix various errors produced by programs.

Entity loading
Having special fileformat for Entity loading sounds good to me. For better flexibility I am strongly considering XML, or better, binary XML. It allows easy "growth" of the format for future.


Textures be part of Material (already possible) but mandatory for Entities loaded/saved the way below
Is there some specific reason why do you like the textures to be mandatory?

Texture formats
PNG and JPG textures would be nice to have and both of these can be added by using GDIPlus Windows library. The only catch is that it is from Windows XP up. That is why I have this feature planned for ThinBASIC 2.x version.

TBGL_EntitySetMaterial
I like this.

I am currently doing big plans on restructuralization of TBGL for ThinBASIC 2.x, that (and work load at ... work) is why my activity on current branch is not that great. Once I have it put together in structured form, I would like to consult it with most active TBGL users. I have planned to publish design document at Q1 2014.


Petr

[ReneMiner]

OK, I re-thought a little.

First your question: Mandatory supposed to mean just every Entity-File-Material has to have a Material- incl. Textures -Property. And if that texture-property within Material-property says 0, then it's just none. Only: It has to be specified - if used or not.

But now back to the thought I just had: it could be probably better to enumerate/index just the raw "DisplayList-Blocks" as these


PolyType
VertexType

numVertices
Vertex()
X, Y, Z [, nX, nY, nZ][, tU, tV][, R, G, B[, A]]

and write the hierarchy thereafter and have just the DL-Block-Index between Translate and numChildren. So Mesh-files can be much smaller if they use the same shape more than once within the mesh - just translated, rotated or scaled, using different material etc. at another place just as their properties say.

But leave you time to think about - I don't know exactly how xml works - I just know how to use it to change the Intellisense-Text of some Microsoft products as MS Small Basic etc. and when I check tB-help it leads me to some of my beloved MS-Sites where I can't not find nothing telling me anything...and I would not like it if I had to learn that stuff to load and save meshes.

[Petr Schreiber]

Hehe,

yes, MS docs are legendary, they use their own dialect of english. The format will be very simple, not necessarily classic XML, but tag based most probably.
It would be done in way easy for users, like EntitySave, so user does not have to learn the format at all in typical case.


Petr

[Michael Hartlef]

+1 to PNG textures. Definitely. And for an ASC file format instead a binary one.