0.40 Module Version
BlitzMax Forums/MiniB3D Module/0.40 Module Version
| ||
| This is the original Module Version of MiniB3D 0.40. As an addition I have added the max2d support path. Usage: Installation is described on the download page: http://klepto2.kl.funpic.de/include.php?path=content/content.php&contentid=16&catid=5&themeid=0 If you have problems with the highlighting you maybe have to run: docmods sidesign.minib3d Enjoy :) |
| ||
| please use a .zip thanks! |
| ||
| the zap is a max intern format. By using bmk unzapmod .../minib3d.zap the module is installed automatically. so, why? |
| ||
| I agree, having a zip version will be more user friendly. Do I have to make anything spetial to have Max2D support? |
| ||
| ok, i will upload also a zip version. no, just use the max2d commands after the renderworld() function. Maybe you should set the Blending mode to Alphablend to avoid the black border around text. eg: a modified version of the collision example:
Import sidesign.minib3d
Strict
Local width=640,height=480,depth=16,mode=0
Graphics3D width,height,depth,mode
Local cam:TCamera=CreateCamera()
CameraRange cam,.5,500
PositionEntity cam,0,10,-10
Local light:TLight=CreateLight(1)
RotateEntity light,90,0,0
Local mesh:TMesh=LoadMesh("media/test.b3d")
ScaleEntity mesh,10,10,10
' create mesh octree - makes collision detection faster (MiniB3D only)
CreateOctree(mesh,200,5)
' set camera entity type to 1
EntityType cam,1
' set camera radius as it's the source collision entity
EntityRadius cam,1
' set mesh entity type to 2
EntityType mesh,2
' use collisions command to enable colliisons between entity type 1 and 2, with reponse 4
Collisions 1,2,4,2
' used by camera code
Local mxs#=0
Local mys#=0
Local move#=0.5
MouseXSpeed() ' flush
MouseYSpeed() ' flush
' used by fps code
Local old_ms=MilliSecs()
Local renders
Local fps
While Not KeyDown(KEY_ESCAPE)
If KeyHit(KEY_ENTER) Then DebugStop
'' control camera
' mouse look
mxs#=mxs#+(MouseXSpeed()/5.0)
mys#=mys#+(MouseYSpeed()/5.0)
RotateEntity cam,mys#,-mxs#,0
MoveMouse width/2,height/2
MouseXSpeed() ' flush
MouseYSpeed() ' flush
' move camera forwards/backwards/left/right with cursor keys
If KeyDown(KEY_UP)=True Then MoveEntity cam,0,0,move# ' move camera forward
If KeyDown(KEY_DOWN)=True Then MoveEntity cam,0,0,-move# ' move camera back
If KeyDown(KEY_LEFT)=True Then MoveEntity cam,-move#,0,0 ' move camera left
If KeyDown(KEY_RIGHT)=True Then MoveEntity cam,move#,0,0 ' move camera right
''
UpdateWorld
RenderWorld
renders=renders+1
' calculate fps
If MilliSecs()-old_ms>=1000
old_ms=MilliSecs()
fps=renders
renders=0
EndIf
SetBlend AlphaBlend
DrawText "FPS: "+String(fps),0,0
SetAlpha 0.5
If KeyDown(Key_Space)
SetColor 255,0,0
DrawRect 30,30,300,300
EndIf
SetColor 255,255,255
Flip
Wend
End
PS: The zip Version will take some time as I don't have access to a proper zip or rar packer from my current (work) maschine. |
| ||
| i dont work a bmk unzapmod 'savepath'/minib3d.zap i open a program command line i insert a file minib3d.zap in C:\Programmi\BlitzMax\mod\minib3d.zap bmk unzapmod C:\Programmi\BlitzMax\mod\minib3d.zap i clik ok and file not open |
| ||
| not the commandline tool of the maxide. the windows console is the keyword (or windows commandline). It looks like the old dos modus. There you have to jump to your Blitzmax\bin folder with cd C:\programmi\Blitzmax\bin after that you could perform this line: bmk unzapmod C:\Programmi\BlitzMax\mod\minib3d.zap |
| ||
| ok work! |
| ||
| Thanks Benjamin. |
| ||
| Thanks, Klepto2. I've uploaded a zip version for all to use so they don't have to bother with the command prompt and unzapping. It can be downloaded from below. http://www.kamikazekrow.com/storage/minib3d.zip |
| ||
| i have a tested example simpleroom from ColdSteel demo 1024 x768 32 full screen with collisions ColdSteel fps 280 minib3d fps 480 blitz3d fps 485 mongia |
| ||
| Superb work klepto! By the way: zap is as userfriendly as a bmx module can be ._. |
| ||
| thx KudosCry :) I agree totally with you, but one problem with the unzapping is the lack of an integration to the maxide, so it is unknown by many people. |
| ||
| picked up some slight problems in linux Include "Includes/TAnimationkeys.bmx" should be Include "Includes/TAnimationKeys.bmx" or it wont compile in linux! (baaaad klepto :D ) and it couldn't find the module interface till I rebuilt modules which is odd (I unzapped it btw, I dont know if manually installing the zip would have the same problems) I have to say I'm blown away by the *considerable* speed improvements, very well done to si and everyone else!! |
| ||
| ups, that damning casesensitive thing (i always forget this ;) ) btw, the module is only precompiled for win32 so you have to build it on your own on the other os. Sorry for not mentioned it before. |
| ||
| Hi, I have small question, after making some testing with VBOs in the new Version it seems that (well that was known before) VBOs only have an advantage when using them with very highpoly surfaces. So I was thinking of an extra implementation for VBOs. Something like CreateVBOMesh and maybe something like TVBOMesh extends TMesh is in my mind. So you could decide by yourself what meshes should use VBOs and which not. So my question is : What do you think about this Idea? |
| ||
| have you compared call lists? you could have a flag in Tmesh.update(cache=false) where true it would create a display list the drawback of call list's is that you would have to create a new one any time you changed any surface property, you'd also need one for each frame of an animated mesh I did some tests with the birdies flying demo when minib3d was in its early stages and got double the speed out of it, but I think that was mainly because of the canyon.b3d object. It would be interesting to see how call lists fair against vbo's as potentially even more info is stored on the card. I personally think that having to explicitly create a VBOMesh goes against the general tendency toward simplicity that minib3d exhibits and in addition call lists are going to be more compatible on older hardware |
| ||
| Of course simplicity would be nice, but klepto2's way would be more oop. So in my opinion I would vote for extending TMesh. But then again it could be better to stay coherent to the B3D/MiniB3D way ;) |
| ||
| Well , I heave tried to integrate DL today, but I think I was going the wrong way. I have created just one displaylist for the whole mesh and if DL are enabled 1 DL is created and the whole update method is stored whithin this list. But I couldn't see any speedimprovements, instead it was a bit slower and the model wasn't effected by the multiple lights or lightmap in the sliding collisions demo. Will have new try later with a DL for each surface. |
| ||
| As I remember State changes is what you want to avoid. So render everything with the same material/texture in one go, then the next etc. I don't think you should group your DLs on surfaces alone, but rather on "materials"/brushes. This might be as simple as sticking surfaces that share the same texture/brush in the same DL. So do use Displaylists, they usually are quite a bit faster |
| ||
| [q]"Hi, I have small question, after making some testing with VBOs in the new Version it seems that (well that was known before) VBOs only have an advantage when using them with very highpoly surfaces. So I was thinking of an extra implementation for VBOs. Something like CreateVBOMesh and maybe something like TVBOMesh extends TMesh is in my mind. So you could decide by yourself what meshes should use VBOs and which not. So my question is : What do you think about this Idea? "[/q] From what I understand about VBO's, they put the vertex data in the graphic cards memory for fast access. it seems like a smart routine could use a threshold to decide what 'hipoly' means. or an additional flag in loadmesh (default to 0) that will identify a mesh as 'static' and therefore bind it as a VBO. I read somewhere that if you touch it with the CPU, you lose alot of the speed benefits. |
| ||
| TCollision.bmx seems to be written as utf8, to be able to read the file under windows correctly I had to convert it to utf8 in pspad. Just to let you know. Why did I look, Collisions now has four methods, whereas B3D only has three,or is the online manual missing a method? edit:
If col.col_method=4
SphereToMesh4(ent,ent2) ' dynamic ellipsoid to static mesh (faster, limited ellipsoid support)
EndIf
That's what I wanted to know :) |
| ||
| Read the readme.txt! |
| ||
| How about letting the CreateMesh command read the number of the vertices an automatically decide if it should use VBOs or not? |
| ||
| so, the VBO problem is solved :) I have integrated it in the way that it is only used for static meshes. After some speed tests I was coming to the conclusion that it is not needed to control the VertexCount before using VBOs because with lower tris/vertices it is as fast as normal miniB3D. But on higher Poly models it increased in speed dramatically. eg: the sliding Collision Demo: without VBO: ~800 FPS (1000 FPS max) with VBO : constantly 1500 FPS AMD 64 3200+ X800 Pro 1 GB Ram So, next point on the list shaders ;) |
| ||
| I won't tell you again how awesome your work is (as well as simons original work on minib3d but he gets the attention he deserves in his threads ^^)!!! |
| ||
| thx, small updated info: Shaders are back in business :) I've modified the collision sample a bit and compiled it with my current Version. Could you please test it: http://klepto2.kl.funpic.de/DL/VBOandShaderDemo.rar Left Mouse Button: Deactivate Shader Right Mouse Button: Deactivate Vsync (to see the real speed ;) W to switch between Wireframe and normal modus. |
| ||
| Will this work with a Geforce4TI-4200 ?? Looks strange... |
| ||
| Don't know exactly: You need VertexObject support for VBOs and at least Shader 2.0 for the shaders. The demo was just a quick test and build together within a few seconds, so the light jumps sometimes. Maybe thats whats looking strange or your gfxcard support shader 2.0 but not completely so that some features are software emulated. MAybe you could post a screenshot. |
| ||
| Read the readme.txt! yes of course, I forgot to do it the easy way, but the code gives me the information WHAT is different and the readme only that there are methods 2 and 4. ...and dynamic ellipsoid to static mesh (methods 2 and 4) |
| ||
| 500-600 FPS at 1024x768x32. AMD 2GHz, XP SP2,GF7600GT (AGP). Wireframe 15-20 FPS. Very nice (yes, light jumps). |
| ||
| Hi Klepto, this is sterling work. Cheers. :) |
| ||
| yes of course, I forgot to do it the easy way, but the code gives me the information WHAT is different and the readme only that there are methods 2 and 4. No, the readme explains in detail the difference between methods 2 and 4: * There are two main 'methods' of collision. Dynamic sphere to dynamic sphere (method 1), and dynamic ellipsoid to static mesh (methods 2 and 4). * Blitz3D's 'Collision' command's 'response' parameter is not used in MiniB3D. Instead, the responses are automatically set to 'no response' for sphere-to-sphere, and 'sliding' reponse for ellipsoid-mesh. * Two methods of ellipsoid-to-mesh collision are offered (2 and 4). * Method 2 is the most flexible. There are no limitations with method 2, however it is slower than method 4. * Method 4 is not so flexible, but is faster than method 2. It is limited in the following way: * If the destination mesh is rotated using RotateEntity on more than one axis, the source entity must use spherical and not ellipsoidal EntityRadius values, e.g. x,y,z are all the same. * If the destination mesh is rotated using RotateEntity on only one axis (eg. the y axis), then you can use an ellipsoidal EntityRadius value, but again only one on one axis, and the same axis (eg. 1,4,1). * Otherwise if you use method 4, it is best to avoid using RotateEntity, or just always use spherical EntityRadius values. * Ellipsoid-to-mesh collisions may be quite slow if the destination mesh contains a large no. of polygons. For large meshes, it is advisable that you use octrees to speed up the collision checking. See 'Octree Notes' below. |
| ||
| Very nice thing :-) 500FPS + here on my 7600Go :) (and core Duo T2500 = 2x 2Ghz) |
| ||
| I think my gfx card is responsible for this (missing support of shaders 2.0 ?!) [img]http://www.photo-host.org/v/video/022848shaders.jpg[/img] |
| ||
| Max2D, you say? Max2D integrated without trouble?! You and Simon, tell the truth now... Are you God? 167 FPS in that example if I run it without VSync, and the shaders look good. (Without shaders and without VSync, I get 400 FPS). That's with a whole lot of other stuff running and in a window, so quite definitely acceptable. (...Grr, beaten by something with a dumb name like 7600Go!). This is with a Radeon 9600 Pro (Heh, "Go") and an Athlon something 1.8 gHz. I see that the place where collisions were not working in Simon's first collisions demo is working now, too, so nice work by all :) Insomnia: Yep, that is running without shaders. (It's fallen back to vertex lighting, which judging by the amount of reflection there, the demo probably isn't really meant to demonstrate). And just a random comment: Klepto's altered collisions example is a great little demo of how some shaders work here. Try playing with values passed to the shader and editing the shader (in media/bump.frag). Also pay close attention to see how values from the main program connect with values in the shader program. Don't be afraid to change variables in there like gl_FrontMaterial.specular to constants such as 0.5. It won't bite, though it doesn't much like it if you put an integer where it wants a decimal. |
| ||
| uhhhhhhhhhhhhhhhhhhhhhhh, I should start reading everything very very slowly and concentrated. Thank you for not simply saying RTFRM.txt ;) Won't happen again (can't promise :) ) |
| ||
| >Klepto Could you show more samples with shaders? |
| ||
| Okay, building this in Linux... One error in minib3d.bmx, on line 61. TAnimationkeys.bmx should be TAnimationKeys.bmx (Capital K!). |
| ||
| yes, the linux casesensitive behaviour is damn thing for me as a lazy windows user ;) . I'm currently working on 3 different places on minib3d: -First creating some shader samples (not easy as I'm not that good shader programmer) -Secondly I'm implementing a terrainsystem (patched LOD based) - and at least I'm building the newton physics lib into minib3d (first succesfull tests got me to apply some rotation and velocity to a sphere Whooo :) ) A new version of the module with samples integrated and some bugfixes will be available soon. (the readme will also be available) |
| ||
| Eek! Your sliding collisions example is crashing at run-time on Local mesh:TMesh=LoadMesh("media/test.b3d") with:Unhandled Exception:Unhandled Memory Exception Error The debug log output is: Building sliding_collisions Executing:sliding_collisions.debug.exe DebugLog:TEXS DebugLog:BRUS DebugLog:NODE DebugLog:MESH DebugLog:VRTS DebugLog:TRIS I have tried enabling the "modules that may be required". I have also included all of the media from Simonh's example that is missing from this one... Curiously, if I change that crashing line to Local mesh:TMesh=CreateCube(), it all builds and runs fine. System specs: CPU: Intel Pentium 4 - 2.80 gHz Memory: 510 MB RAM Display: Intel 828625G Graphics Controller (96 Mb RAM) I will see about another example in a moment... Edit: Okay, this also happens in the same place with Simon's sliding_collisions example if I change Import "MiniB3D.bmx" to Import sidesign.minib3d. I would try rebuilding modules, but I don't have msys :( --- Update! With both examples, the crash appears to be on Line 203 in TMesh.bmx (in the FreeEntity method of TMesh). glDeleteBuffers(5, surf.vbuffers) Again, since I can't compile modules I can't really help with this one... hope I've provided enough information. Looks like it may be incorrectly thinking the hardware has VBO support? |
| ||
| Your card is a serious problem I fear. Simply because it is no 3D card and it is, as all Intel before Extreme2 (GMA 900), very OpenGL incompatible. You can't use any of the efficient now adays technic with a 2D card like that one I fear ... (it works for DX7 but only because DX7 allows emulation of some stuff, as OpenGL does, but not on Windows unless you install Mesa3D. Thats because even WinXP only emulates up to OpenGL 1.1! *vista emulates till 1.4*) For 3D programming you will most likely need to get a 3D card. |
| ||
| Dreamora is right, but normally it should detect if VBO support is there, but sometimes this test seems to fail, don't know why. Try adding this line right after the Graphics3D in the samples : THardwareInfo.VBOSupport = False Hopefully this should fix it. |
| ||
| Okay, thanks :) Gladly it's not my card. I guess as long as someone can easily slip in a manual disabling of VBO support it will work as well as possible... I'll try that next time I have access to that computer. |
   |