filling in the blanks

BlitzMax Forums/MiniB3D Module/filling in the blanks

skidracer(Posted 2009) [#1]
I am interested in contributing some code to increase backward compatibility of minib3D.

Main feature will be texture buffer commands using latest axe.pixmapgraphics module and a tidier inc/TTexture.bmx file.

After stubbing out the following an old .bb project now compiles and runs in .bmx. The following is a list of commands that I would like to stub or make functional in next few days, if anyone else has any requests please post.




jkrankie(Posted 2009) [#2]
these look like great additions :)

Cheers
Charlie


*(Posted 2009) [#3]
What about:
CreatePlane
AlignToVector
SetAnimKey
AddAnimSeq

Also sorting out the rotateentity and turnentity commands so they work like Blitz3d's (this one is the BIGGEST issue to writing space games using minib3d).


RifRaf(Posted 2009) [#4]
well, i dont know enough about what is already in there to make a useful specific suggestion.. but when i get around to bmax ill probably go straight to minib3d and I would love to be able to port sprite candy/sprite candy gui over to minib3d, it appears to have what it needs for that at a glance, but if anyone else if familiar with both sc and minib3d and knows of any missing features please speak up :)


KronosUK(Posted 2009) [#5]
+1 on turnentity. This is probably my number one peeve with Minib3d.

Loadmesh including .3ds and .x models would be nice.

Sound is definitely a good one though. I'd forgotten we didn't have that in minib3d:)


Difference(Posted 2009) [#6]
Looking good.

On a different note I have a few bugfixes I'm currently hunting down and complete, so I'm hoping you can include in the next version. I'll post them as soon as they are done


SLotman(Posted 2009) [#7]
What's missing:
CreatePlane, LoadTerrain, TerrainDetail, TerrainShade and AlignToVector.

And of course, if it's still a problem, fix RotateEntity and TurnEntity; I didn't try those yet...


skidracer(Posted 2009) [#8]
Eek, new transformation model is required, i will put on hold the new stuff and see what can be done.


impixi(Posted 2009) [#9]

Eek, new transformation model is required, i will put on hold the new stuff and see what can be done.



If you're referring to Euler-/quaternion- transformation-related issues, it has been discussed before. Search this forum for 'quat' and you'll find the following potentially helpful threads:

* Implementing Quaternions
* TurnEntity - Quaternion Example
* TurnEntity (Around Axis)
* Matrices

… among others.

Personally, I think MiniB3d offers the best chance of gaining a full-featured 'semi-official' cross-platform 3D engine, *if* capable individuals can 'fill in the blanks', building on what simonh has already provided.

The way I see it, the significant current omissions are:

* File-formats other than B3D – Potentially provided by an assimp wrapper?
* 3D audio – Potentially relevant code here.
* LOD Terrains – There's code floating around here, but partially not public domain.
* Planes - Should be easy to provide by 'OpenGL gurus'.

And further down the track:

* Pixel- and vertex- shader support - Klepto2 had working code years ago with his extended version of MiniB3d. Mark also had an interesting shader system in Max3D. Could the relevant code be ported?

* Physics – Mark had some nice ODE(?) things going on in Max3D. Could the relevant code be ported?

At that point, MiniB3d would need to be renamed to something more appropriate to its capabilities.


*(Posted 2009) [#10]
Minib3d wouldn't need to be renamedas it's not a complete language in it's own right but a addon for max that allows blitz3d functionality


Difference(Posted 2009) [#11]
@impixi : I've made an assimp wrapper, and I'm currently updating it.

http://code.google.com/p/blitzmax-assimp/

It's working ok, just needs a little tweaking for static meshes to be ok.
If anybody would like to join the project, they are more than welcome.

Are you looking for a different approach?


slenkar(Posted 2009) [#12]
no need for skid to add physics, that might be too much work.


Amon(Posted 2009) [#13]
This is good stuff guys. Look forward to testing the new fixes and updates.


*(Posted 2009) [#14]
skid: if you can get the rotations to work like Blitz3d then it will bring Minib3d out of the darkness in my opinion. at the moment its an amazing piece of work but not very much good for space games unless this is sorted.


GameCoder(Posted 2009) [#15]
Yep! Rotations fixed for space games would be cool.

Regards,
Amon


plash(Posted 2009) [#16]
I don't think we should be going backwards just so people have to 'type less' to convert Blitz3D code to BlitzMax.
In any case, for people who don't like wrapper functions for 'backwards compatibility', I would recommend sticking functions like these in a different module:
Flip3D
Viewport
Origin
stringheight
stringwidth


Minib3d wouldn't need to be renamedas it's not a complete language in it's own right but a addon for max that allows blitz3d functionality
That has nothing to do with it. Sure it could be renamed if skid deems it necessary, but that doesn't at all mean it would have to become a language to get that.

EDIT: And that does not mean it would have to be renamed to 'B3D'..


skidracer(Posted 2009) [#17]
I'm hoping to have some help for this update.

Those interested in testing as I go would be doing me a big favor.

Unfortunately I started ripping into some texture buffer stuff before focusing on the entity transform fixes so this version has broken animtextures and more I expect.

It does have new entity transform, current behavior is that turn is applied only to local transform TEntity.mat and a TransformWorld is required to update everybodies global state. That means use of global flag for reading entity state needs call TransformWorld first.. todo


The upshot is the new system is a bit more optimal.

If anyone wants a challenge, checkit out from here http://max-edit.googlecode.com/svn/trunk/mod/sidesign.mod

and get the spinningcube demo to degenerate. This is a work in progress so any other kind of testing is possibly bit of a waste of time.

The fix is to enable the matrix freshen method but I'll be darned if I can write some code that will get this theoretical feature of my approach to occur.

another version of spinningcube is also required that demonstrates gimble lock in an automated manner so b3d / minib3d behavior can be compared

TIA, anyone who wants to help


Ked(Posted 2009) [#18]
Downloading now!


Difference(Posted 2009) [#19]
@skidracer; Compiles and runs spiningcube well.

Other test (firepaint3d etc) show no objects, but seems to run

Snow Leopard, NVIDIA 9400m , Mac Mini


skidracer(Posted 2009) [#20]
I reverted TTexture.bmx so textures should be back working. Will aim at firepaint compatability next, ta!


skidracer(Posted 2009) [#21]
Spinning cube now has spinning kid. Sprites nearly working...


Difference(Posted 2009) [#22]
Spinning cube with spinning child working

spinningsprite too:



Amon(Posted 2009) [#23]
Working fine so far!

Hey Skid, would it be possible to have module addons for minib3d which could be paid for i.e. Shadows etc?

If you could work on a shadows addon for minib3d I would gladly pay.

Yes/No?


*(Posted 2009) [#24]
Tbh I agree once the basics are fixed so it's like blitz3d anything else should be charged for


skidracer(Posted 2009) [#25]
With the kind of embarrassment on display by some vendors in the local 3d marketplace, it's difficult not to consider stepping up to the plate.

As most people will agree, getting the BASICs right is a lot harder and involves a lot more work than promising some flash deferred design, although there are some mighty fine tutorials about to help with such activity should such opportunities present...


QuickSilva(Posted 2009) [#26]
This is looking promising, please do keep up the good work skidracer.

The hard work you guys put in (BRL) is very much appreciated. Having rock solid products is something that you do not see much of these days but Blitz has always delivered the goods.

Jason.


skidracer(Posted 2009) [#27]
BRL? I am strictly AC these days, BRL do not operate maxgui @ share-it, AC gets that direct (and passes on chunk to Seb).

Also, contrary to old wikipedia articles, BRL didn't use to be Acid, that was AC also.


skidracer(Posted 2009) [#28]
In order to test against minib3d 0.53 I've had to move my wip module to here:

http://max-edit.googlecode.com/svn/trunk/mod/axe3d.mod

This folder also contains a full build of marks bmx3d engine in the m3d.mod folder along with assimp and ode mods so you may want to check out just the new minib3d.mod folder in axe3d.mod to follow recent development.

m3d does still build and run a spinning cube with shadows so I'm interested if it's missing anything from the bmx3d repository before it was retired.


This is just an idea at the moment, but here is bbdoc from experimental new axe3d.blitz3d.mod:

The Blitz3D Compatability Module contains command definitions and documentation for using the standard Blitz3D API in a BlitzMax environment.

It also provides a standard interface to 3D graphics engines by abstracting a standard driver class similar in design to that of the MaxGUI module.

The TEntity type, like TGadget is a monolothic interface. This allows the driver developer maximum freedom to abstract the different Entity types the way they see fit while benefitting from a predefined and documented functional interface.

+Entities




The idea being there are 3 existing 3d engines (blitz3dsdk, minib3d, and m3d) that could with a little labor provide working drivers for the standard interface.


Difference(Posted 2009) [#29]
The driver thing is an excellent idea.
There are a few more engines, DreDe beeing the best in my opinion. http://blitzmax.com/Community/posts.php?topic=87890#997213

Personally I'm unhappy to see mini3d fork before the basic transformation routines are in place.
I'd much prefer efforts to go into the same code base.

Your assimp module seems like just the base you helped me set up, and I recommend anyone wanting to test out assimp with minib3d to try out and contribute to mine : http://code.google.com/p/blitzmax-assimp/
[EDIT] : Ok I get it, your assimp is for m3d and must be there.
You can get rid of boost, by using the --noboost flag.


BTW: Did you put in any of my/others reported fixes for minib3d in your new fork and/or are you going to?

Have you shared your ideas with simonh or are you going solo?


degac(Posted 2009) [#30]
Just for curiosity, I've tested the spinningcube.bmx example in M3d - why it takes several seconds (15-20) to be compiled.
Same behaviour with SpinnngCubePanel.
And at the 'exit' (in this case) the program takes some second to close.
Is it normal?
I remember time ago some test with Max3d/dll+wrapper, and it didn't take so much time.

Another thing: in both the examples if I turn debug mode OFF, I can't see anymore the 'spinning cube'... only the 'ground' and the 'sky'.

Edit: tested with Bmax 1.36


skidracer(Posted 2009) [#31]
Hi Peter,

Yes, the m3d stuff has been there since bmx3d first got published.

In regards to simonh, I was hoping to surprise him with tidy patch for working / tested transformations and go from there. However being of inquisitive nature, I'm doing a bit of experimenting on the front end to see how feasible standard interface module is.

I have been meaning to check out your code and catch up with all contributions.

DreDe beeing the best in my opinion.


That is nice and clean, but no lights?


Difference(Posted 2009) [#32]
Nice to see a m3d version that compiles natively under blitzmax, fps is very slow for me.

If it is of any interest, /Community/posts.php?topic=87805 makes the latest versions downloadable here:

http://www.xlsior.org/temp/Max3D.zip (118MB)
and maybe also http://github.com/nilium/max3d


Keeping my fingers crossed for a revised transformation system in minib3d.

True, no lights in DreiDe, but maybe a nice base for something. 159 is most complete, 162 form Vertex website is newest.


skidracer(Posted 2009) [#33]
OK, updated m3d to latest, and added first version of the blitz3d compatibility module currently named axe3d.mod

the spinning cube example in axe3d.mod/doc should work with all drivers:

' change Flip -> bbFlip for sdk testing

Strict

Import axe3d.m3d

'Import axe3d.b3dsdk
'Import axe3d.minib3d
'Import sidesign.minib3d

'Import axe3d.drivers - not yet implemented

Global cube:TEntity
Global cam:TEntity
Global light:TEntity

Graphics3D 800,600

cube=CreateCube()
ScaleEntity cube,1,1,1

cam=CreateCamera()
MoveEntity cam,0,0,-2

CameraClsColor cam,185,0,40

light=CreateLight()
MoveEntity light,-25,25,-50

While Not KeyHit(KEY_ESCAPE)
	TurnEntity cube,1,2,3
	UpdateWorld
	RenderWorld
	Flip
'	bbFlip
Wend


I can now get back to fixing scaling in the new minib3d transformation system , apologies for the delay but I wanted to be able to test the different 3D engines out side by side so this seemed like best initial step.

The design is work in progress, with it all being purely abstract except for base TEntity extending TMatrix, I'm not sold on this bit quite yet but will see how things go.

Peter, I have added you as committer http://code.google.com/p/max-edit if you are interested in helping, would you be able to commit your fixes independently? I have removed assimp, so hopefully we can build standard interface from your module to the proposed compatibility layer.


Difference(Posted 2009) [#34]
I think what you are doing looks very good.

The concept of having a mutual interface for different 3D engines aka drivers is excellent.

I had a little trouble compiling because I don't have the blitz3d.blitz3dsdk module, but got it compiling by removing b3dsdk.mod AND the m3d module? To get more people in on this, I think there should be a flag for including/excluding the blitzsdk.

I'll be happy to put in my small fixes via svn.

Regarding the assimp module, I'm open for any road forward.
If you (and anybody else) could make a list of functions that needs implementing, I'll get on it.


Panno(Posted 2009) [#35]
thx skid


skidracer(Posted 2009) [#36]
I cleaned up m3d garbage while on linux yesterday. Will disable b3dsdk by default which did get changed to ?win32.

Today I am on G3 @ 400mHz and feeling suprisingly spritely.

If OSG does not make it on the rendering front I think it may make candidate for most useful util module as it is has a pretty rich plugin set.


KronosUK(Posted 2010) [#37]
I think adding shader support to minib3d would really pull it out of the stone age. When you look at FastExtensions for Blitz3d and the difference that has made, its pretty amazing.

I've tried using Klepto's version of minib3d but it no longers seems to work with current version of blitzmax.


Sake906(Posted 2010) [#38]
Something very important must be considered: hierarchical animation support.

Right now, from what I've read around, it is impossible to load keyframed b3d files consisting of a structure made of parent-child elements animated; no bones+skin.

What gives? it allows you to have robots or mechanical stuff; currently the game I'd like to port has a lot of hierarchy-animated b3d robots and sadly I cannot do so on minib3d. It surprises me you got bone animation working and not this which I consider is much more simple and fundamental, as bones in Blitz3D behave exactly the same (you can manipulate them like if they were pivots, which is something I doubt you can do on minib3d, correct me if I'm wrong)

I am suspecting this is extremely dependent on the transforms issue, so I hope that when you have that solved, the rest turns out to be fixed as well. I guess "setanimkey" also depends on all of the above.


Leon Drake(Posted 2010) [#39]
I thought vertex based animation (at least that's what i think your referring to) was considered morph animation. From my understanding I'm pretty sure minib3d supports morph animation.


jhocking(Posted 2010) [#40]
a) No he's not talking about vertex animation. That's how md2 files are animated; he's talking about how 3ds files are animated.

b) md2 animation isn't supported either. minib3d only has skeletal animation.


Incidentally, I want to third this request:
Pixel- and vertex- shader support


Literally the only reason I switched to other development tools for future projects is because I wanted shaders for realistic water; BlitzMax is still my favorite programming language. Doing shadows with shaders would be pretty sweet too.


Leon Drake(Posted 2010) [#41]
hmm. as of late i have been moving many of my projects to java using the jmonkeyengine. ;p


jhocking(Posted 2010) [#42]
I was pretty jazzed about jme at first, but I'd also never used java before.


salric(Posted 2010) [#43]
Hi Skid,

Would you be kind enough to advise on when you expect the commands in your original post to be implemented? (I'm really looking forward to porting some old B3D apps that make extensive use of buffers).