axe3d update

BlitzMax Forums/BlitzMax Programming/axe3d update

skidracer(Posted 2009) [#1]
Hi, if anyone is using axe3d modules on SVN please don't try and update until further notice. Current revisions are in state of flux.

More details in worklog.


xlsior(Posted 2009) [#2]
Thanks for the heads up.

By the way, are you aware that your axe.v8 is broken in Blitzmax 1.36 as well?


skidracer(Posted 2009) [#3]
I have just revived my iMac and will be testing all mods against 1.36 on all platforms over next few days.


byo(Posted 2009) [#4]
Wow, the OpenSceneGraph port looks excitingly interesting!
Keep up the awesome work, skidracer.


skidracer(Posted 2009) [#5]
OK, it's a beast, currently disabled.

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

There is problem with linker i think in bmk where the Open Scene Graph basic module is too darn big. Those wanting to cook their processors and proceed with the test file will only get a successul link of osgtest.bmx by pruning back the import list after enabling basic module build in osg.bmx.

Latest axe3d.axe3d module is up which is misnomer for blitz3d compatability driver module.

It is somewhat working with blitz3d.blitz3dsdk and there is a fork of Si's minib3d known as axe3d.minib3d which is my local development branch of sidesign.minib3d. Mark has kind of given me his blessing on this one in regards to m3d, so will be putting in a bit of effort in coming weeks as I remain luckily unemployed and restless.


degac(Posted 2009) [#6]
Little OT


in coming weeks as I remain luckily unemployed and restless.



Well, I hope for you a new 'good' work.

I don't want to change your plans, but do you have never planned to update/re-work/refine (or what you think) MaxGUI (with the Sebholl indications)?
There are still some 'missing gadgets' in the MaxGUI product, and this could be the chance to 'fill the gaps' with an 'update price'...(money is important...) - I know this 'break-up' the non-written law of BRL 'buy once and update forever', but as I know MaxGUI is not a 'BRL branded' product this could be done (and you can still decide the right-price of the update).

The advantages: for you some money, for MaxGUI users a 'more' complete module, for BRL something to use to sell BlitzMax as product for 'business' application and not only for games...

Just an idea.

Cheers


REDi(Posted 2009) [#7]
Interesting, I've been playing around with osg and blitzmax myself for a while, I ended up building osg with cmake and creating separate static and dynamic modules, as I found the linking time for the static build a bit much for development purposes.

I also came across the "too darn big" issue.

Out of interest, are you planing on doing a B3D driver with osg, or something more advanced (shaders etc)?


jpavel(Posted 2009) [#8]
The linker shipped with BlitzMax is an almost four year old version of ld.exe, from GNU Binutils. Maybe you can try to swap a more recent version into BlitzMax\bin ? I'm not sure if this will fix the problem of too big a link size, or even work at all, though.

URL to most recent ar.exe and ld.exe:

http://www.box.net/shared/ntgy89igcm


skidracer(Posted 2009) [#9]
I have removed ld and ar from my blitzmax bin folder.

My initial problem was that bmk flattens archives using undecorated object file names so all the different version.cpp files in the module were ending up overwriting each other in the .a archive.

Now my main problem is the speed of ar and ld doing any kind of operation on said 20 meg .a archives. I'm wondering if it is possible to emulate ram drivers in bmk by creating named pipes connected to ram banks. If so, that may make windows builds a little more comparable to linux where the file system is a little more optimized on my drive.

OSG also has a wrapper folder which may just be public symbols. Hopefully it will be possible to link with static at normal speeds once something is done about the sheer number of symbols ending up int the .a perhaps.

I have tried axe3d.osg.mod source from a blank codeblocks static mingw project and verified osgtest.cpp does run and display blank scene happily so things look possible. I haven't suffered build times like this for a few years. I wonder what kind of hardware the Nasa and Boeing engineers use when playing with this stuff.


Brucey(Posted 2009) [#10]
Do you need the whole API in one chunk?
Is the API modular at all? (like wx or qt is, for example).

One workaround is to split it off into smaller compiled parts, stored in separate modules - you'lll only be linking in the parts you need then.


skidracer(Posted 2009) [#11]
I split off the plugins, not sure what size that archive builds to now.

I will split off the viewer / display toolkit next and hopefully end up with three 10 meg archives. The poor performance of ar and ld is only unworkable as the .a files grow past 20 meg but link times are hopefully due to large number of unnecessary symbols.


REDi(Posted 2009) [#12]
I wonder what kind of hardware the Nasa and Boeing engineers use when playing with this stuff.

I would assume they go the dynamic route anyway, as using osg as a static library is a fairly new addition.

I will split off the viewer / display toolkit next and hopefully end up with three 10 meg archives

The complete build of osg comes out at ~90mb with all the plugins, it is a beast! :)


Difference(Posted 2009) [#13]
I'm wondering how OSG fits in with the 3ddrivers concept with tEntities that extend tMatrix?

I'd also like your view on how and where an model import module (assimp), should plug itself into the different drivers/engines with some chance of reuse.

In the case of minib3d, it currently seems that tModel.LoadAnimb3d does the actual loading.

I'd like to find a way where people could disable the use of assimp with a flag (or rem an Import statement), and that loading with assimp was then done silently in the background.

For all drivers, with or without assimp, a common function for getting available formats for mesh/animation readers would be a good thing.


Difference(Posted 2009) [#14]
Thinking a little more about how to implement model loaders, it seems a good idea, taht they can be used side by side, and that they do not override whatever Loadmesh() a driver/3d module has.

Importers should be able to live together, so that their resulting meshes can be compared, and so that they can supplement each other, providing the broadest range of import formats.

Where are planning Loadmesh() to end up in the driverbased setup?


skidracer(Posted 2009) [#15]
I've committed a new model mod that provides basic interface implementation of the driver without any display dependencies. A concretemodeldriver is included so toolchain utilities can be coded in light weight manner using the standard API. Bone, vertex weight and animation support still to come.

My current plan is for minib3d and m3d to extend from this modeldriver while the b3dsdk will need to run a secondary concretemodeldriver to host loadmesh extensions.

I would imagine loadmesh itself could end up similar to loadpixmap with its abstract stack of loaders although I'd be happy with simple discreet LoadLWO:TEntity() LoadCollada:TEntity() function names when it comes to such additions.


Difference(Posted 2009) [#16]
I think I liked it better when you where just putting in a new transform system to minib3d.

Maybe it will all be clearer when things fall into place a little more.

For now, I think I'll try to do my assimp/minib3d intergration with the original minib3d.


skidracer(Posted 2009) [#17]
The new osg module collection now opens a view on both Linux and Win32. Woot!

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

test is in axe3d.mod/osg3d.mod which is going to be renamed shortly. axe3d.osg has been removed which may require rebuild all modules for anyone silly enough to investigate my progress.

Splitting the api into multiple modules has sorted all compilation problems and link times are now sane. I am back to being quietly optimistic about this engine.

In other news skidmarks construction kit (aka axe3d unit test) now runs (not well) using axe3d.b3dsdk driver.


Brucey(Posted 2009) [#18]
Splitting the api into multiple modules...

Yay! ;-)


Matthew Smith(Posted 2009) [#19]
skidmarks construction kit


Even more Yay! Will it see the light of day Simon??


skidracer(Posted 2009) [#20]
The OSG 3d test now loads and displays png billboard [edit](and .3ds!) on both linux and win32, my G3 Mac unfortunately not so good. Run the following script from your BlitzMax/mod folder for latest:
svn co http://max-edit.googlecode.com/svn/trunk/mod/axe3d.mod axe3d.mod
svn co http://max-edit.googlecode.com/svn/trunk/mod/osg.mod osg.mod
svn co http://max-edit.googlecode.com/svn/trunk/mod/osgplugins.mod osgplugins.mod


Also the m3d driver now has full surface and texture buffer support. I'm hoping to have this driver running my game next and then it's minib3d's turn for some new paint...


xlsior(Posted 2009) [#21]
Looks like there are additional dependencies to blitz3dsdk.mod ?

Is that the full-blown commercial product, or is is a freebie interface to it?


REDi(Posted 2009) [#22]
Wow that's great skid! :D

I noticed after pressing the s key a few times (to show the stats) that freetype isn't working ATM, renaming the freetype plugin module to something else fixes it (osgplugins.mod/freetypelib.mod or whatever)

Looking forward to this one, it really is a nice piece of kit!


skidracer(Posted 2009) [#23]
Once I changed to a 16 bit display the G3 started working with the osg viewer just fine so I'm happy.

The blitz3dsdk dependency should have been disabled by default, oops, that lib is simply a wrapper for the real thing.

Will fix freetype also, thank you for introducing me to the s key REDi, more smiles.


REDi(Posted 2009) [#24]
np mate, here's some more...

f to switch between full screen and windowed
1-4 to switch camera manipulators (trackball, flight, drive and terrain)
space resets camera position
w changes rendering mode (poly, wireframe and points)
...

They are added in as manipulators and event handlers in osgtest.cpp

I do like the stats handler, it even draws usage graphs per thread, very cool.


skidracer(Posted 2009) [#25]
I've added the jpeg and dae plugins to osgplugins.mod, now things start to get problematic again.

The jpeg plugin is active but fails miserably. It's using fresh jpeg7 module based on latest from IJG but like the freetype module something is up...

Also added to osg.plugins is a colladadom module, I stripped 1.5 and tried importing the mingw external-lib archives they ship with but linking is not quite there yet. Enable in axe3d osg3d.bmx import list if you want to help here...


REDi(Posted 2009) [#26]
*EDIT* hmmm :/ *EDIT*

The osg plugin loader is a good one to get going, as it shows off the particle system and everything.

Some sample osg files can be found here...

http://www.openscenegraph.org/projects/osg/wiki/Downloads/SampleDatasets


REDi(Posted 2009) [#27]
skid, in "jinclude.h" (jpeg-7) there is a line commented out that should include "jconfig.h", if I uncomment that line then jpeg-7 works here.

I'm using the 2.9.6 version of OpenSceneGraph, but I assume this should work for you also.