MiniB3D
BlitzMax Forums/MiniB3D Module/MiniB3D
| ||
| MiniB3D V0.2 is now available to download from www.si-design.co.uk Please give it a go and if you find any issues then let me know. It's been tested on Windows and Mac. |
| ||
| Nice one Simon. Just got your email too. Look forward to playing with MiniB3D ;P |
| ||
| WOw!!! Amazing! Keep up the good work!! |
| ||
| :O That's awesome. :) Would love to see the command set completed. The full Blitz3D command set in Max would be FAB. |
| ||
| wow this is really awesome. PLEASE finish this :) |
| ||
| pretty cool stuff. keep up the great work :) since you mentioned that it hadnt been tested in linux yet i thought id give it a whirl for you. i received a crash that had already been documented for linux here: http://www.blitzmax.com/Community/posts.php?topic=57783 i dont think this has anything to do with your functions but then again im not sure. |
| ||
| engage !! |
| ||
| Excellent. :) Are you going to implement the collision instructions? |
| ||
| Very good! |
| ||
| Collision commands - probably not, as I intend to use ODE for the collisions in my own game. Once I've implemented sprites, some more animation commands and texture flags that will probably be it from me, bar bug fixes and optimisations (oh and a DX driver). If someone else wants to add terrains, bsps and the other stuff then feel free, but my intention with MiniB3D was always to create only a lightweight version of B3D. |
| ||
| Mindblowing! |
| ||
| great work, Simonh. I see that you've made and object oriented base for this, which is great... A question though: Would you mind renaming the methods of the types, so it doesn't contain the type name itself? what I mean is that I see you've got a type called TEntity, and it has methods like PositionEntity(), MoveEntity() etc. Could you change those to just Position() and Move() etc.? it would make it just a tad simpler for me to do: mycube:TMesh = TMesh.CreateCube() mycube.Move(1,0,0) You could still keep the PositionEntity() etc. for the Procedural approach, to keep it similar to B3D. I wouldn't mind changing the method names myself, but if you later updated this engine, my efforts would be lost.. :( |
| ||
| Probably not Lars, I think there's too much potential for confusion - for example PositionEntity + PositionMesh, NameEntity + EntityName, plus I'd rather keep things consistent with B3D. |
| ||
| Hi, what is the purpose of this? Being able to take bb code and compile it in max? |
| ||
| Hi, what is the purpose of this? Being able to take bb code and compile it in max? |
| ||
| So you can convert your 3D programs to Max, and run them on a Mac. |
| ||
| WOW! Keep up the good work. Will this be free? |
| ||
| This is awesome!!! I'm currently working on my own 3D module with a command set that is exactly the same as Blitz3D. @simonh, You won't mind if i used your CreateSphere, CreateCylinder, and CreateCone functions, will you? |
| ||
| I have some problems both on win and Linux but it gives me errors on "Renderworld". win: unhandled memory exception error Linux: appstub error 11(if i remember right) Where could the error be? |
| ||
| Will this be free? Yes it's free. @simonh, You won't mind if i used your CreateSphere, CreateCylinder, and CreateCone functions, will you? Those functions were actually written by Todd Riggins, but you're free to use any of the code. I have some problems both on win and Linux but it gives me errors on "Renderworld". What program gives you the error? Does running it in debug mode give a more detailed error message? Feel free to email me the program and I'll look into it. |
| ||
| Simonh, Whats the policy on community input into MiniB3D. |
| ||
| Very good stuff! I hope that you get to finish this as I can't use B3D after using MAX !!!! |
| ||
| OK, I don't understand...... Simonh, you are belonging the BRL team, aren't you?? And everyone knows that Mark is writting a 3D module. And you are also writting a mini-3D module. And your idea of using the same command as B3D is great, and should please Mark Sibly. So does that mean that you mini-3D-engine will be part of the engine of Mark???? If not, I don't see a reason why, and that would be crazy. Mark could saved a lot of time with your implementation.... Let us know.... |
| ||
| Very very very good work! I've been modifying the B3D loader to load B3D files the way B3D does- ignoring missing textures. Time is short at the mo, but this is a better way than chucking up on a missing texture :) I suppose you could just make it create a 1x1 or so small empty texture :-) Really, excelent work :D |
| ||
| Anyone other is experiencing my same problem? |
| ||
| very good work!! thanks mongia |
| ||
| looks solid, not tested in linux yet! interestingly it does the same distortion as b3d with the default fov...! are you going to take it further than b3d ie shadow volumes, shaders etc? |
| ||
| So does that mean that you mini-3D-engine will be part of the engine of Mark???? No! This is just a personal project, nothing to do with BRL or Max3D. And er, I don't think Mark needs to borrow any of MiniB3D! Whats the policy on community input into MiniB3D. Community input is more than welcome, if you post additions/changes here or email them to me I'll add them to the next release. Mongia has already provided a PointEntity function, thanks dude! Very very very good work! I've been modifying the B3D loader to load B3D files the way B3D does- ignoring missing textures. Time is short at the mo, but this is a better way than chucking up on a missing texture :) Yes, good point. That needs changing. interestingly it does the same distortion as b3d with the default fov...! Yeah that took some figuring out. The answer is that for field of view, you have to multiply the zoom value (default 1.0), by the viewport ratio - no idea why Mark does it like that. are you going to take it further than b3d ie shadow volumes, shaders etc? Probably not, Max3D will take care of all that stuff :) |
| ||
| yeah but max3d is at least 7 months away and could end up being like maxgui... which means another 4 months or so before its "production" ready |
| ||
| 7 Months? Russell |
| ||
| 7 Months? Yeah -- Mark said "around christmas" as his expected release date in another thread a couple of days ago. |
| ||
| B3d was allways looked perfect. I had the demo.... I have no idea what I may losted... But can this MODULE be a documented one? |
| ||
| V0.2 now available - the full sprite and animation command sets are now supported, plus most of the texture commands (scroll, position etc), and a few other new things. |
| ||
| Si, this is a fine piece of work! Thanks. |
| ||
| I thought you were dead, James. |
| ||
| This is looking cool. Nice work Si. :) |
| ||
| Simon you are a legend, this is really good work, keep it up ! |
| ||
| One word. EXCELLENT |
| ||
| Thank you Simon! |
| ||
| Ive just downloaded it and had a quick look. Well done Simon, this looks fantastic! Thank You!!! (and keep up the good work) |
| ||
| Awesome work so far, keep it up! :) |
| ||
| thank you simon ... and now : german... Teile Weisheit mit mir, oh Gottgleicher! do'nt try this in babelfish ;) |
| ||
| I thought you were dead, James. No, just out of beer, which is probably very similar. |
| ||
| Very impressive. What is the best way to get b3d functions documentation? Books? Buying b3d just for a/the manual? I am on a Mac, so I am not interested in anything other than the functions documentation. PLS |
| ||
| Would this do?: http://blitzbasic.com/b3ddocs/docs.php |
| ||
| Simonh, what is your roadmap for next versions ? |
| ||
| I'm currently working on optimising everything, i.e. implementing entity fustum culling and a few other things. I hope to release this version within a few days. After that I'm not sure, but I'll probably have a look to see if I can get some sort of collision system working. |
| ||
| only recently purchased bmax+maxgui so just finding my way round :) Is it possible to use maxgui with minib3d? |
| ||
| Hi! Wireframe: glPolygonMode(Face, GL_LINE) -------------------------------------- LoaderMatrix: I think, you must only multiply incomming vertices with this matrix. -------------------------------------- SetCubeFace: SetCubeMode: glEnable(GL_TEXTURE_CUBE_MAP) glBindTexture(GL_TEXTURE_CUBE_MAP, Self.TextureID) glEnable(GL_TEXTURE_GEN_S) glEnable(GL_TEXTURE_GEN_T) glEnable(GL_TEXTURE_GEN_R) Reflectivemode: glTexGeni(GL_S, GL_TEXTURE_GEN_MODE, GL_REFLECTION_MAP_ARB) glTexGeni(GL_T, GL_TEXTURE_GEN_MODE, GL_REFLECTION_MAP_ARB) glTexGeni(GL_R, GL_TEXTURE_GEN_MODE, GL_REFLECTION_MAP_ARB) Projectivemode: glTexGeni(GL_S, GL_TEXTURE_GEN_MODE, GL_NORMAL_MAP_ARB) glTexGeni(GL_T, GL_TEXTURE_GEN_MODE, GL_NORMAL_MAP_ARB) glTexGeni(GL_R, GL_TEXTURE_GEN_MODE, GL_NORMAL_MAP_ARB) -------------------------------------- CameraProjMode: Type TFrustum Function SetPerspective(Matrix:Float[], Zoom:Float, Aspect:Float, Near:Float, .. Far:Float) Local FPN:Float, NMF:Float Rem | Zoom | | ------ 0 0 0 | | aspect | | | | 0 Zoom 0 0 | | | | Far+Near 2*Far+Near | | 0 0 -------- ---------- | | Near-Far Near-Far | | | | 0 0 -1 0 | End Rem FPN = Far+Near NMF = Near-Far Matrix[ 0] = Zoom/Aspect Matrix[ 1] = 0.0 Matrix[ 2] = 0.0 Matrix[ 3] = 0.0 Matrix[ 4] = 0.0 Matrix[ 5] = Zoom Matrix[ 6] = 0.0 Matrix[ 7] = 0.0 Matrix[ 8] = 0.0 Matrix[ 9] = 0.0 Matrix[10] = FPN/NMF Matrix[11] = 2*FPN/NMF Matrix[12] = 0.0 Matrix[13] = 0.0 Matrix[14] = -1.0 Matrix[15] = 0.0 End Function Function SetOrtho(Matrix:Float[], Zoom:Float, Left:Float, Right:Float, .. Bottom:Float, Top:Float, Near:Float, Far:Float) Local RML:Float, TMB:Float, FMN:Float Rem | 2*Zoom | | ---------- 0 0 0 | | Right-Left | | | | 2*Zoom | | 0 ---------- 0 0 | | Top-Bottom | | | | -2*Zoom | | 0 0 -------- 0 | | Far-Near | | | | Right+Left Top+Bottom Far+Near | | - ---------- - ---------- - -------- 1 | | Right-Left Top-Bottom Far-Near | End Rem RML = Right-Left TMB = Top-Bottom FMN = Far-Near Matrix[ 0] = 2.0/RML Matrix[ 1] = 0.0 Matrix[ 2] = 0.0 Matrix[ 3] = 0.0 Matrix[ 4] = 0.0 Matrix[ 5] = 2.0/TMB Matrix[ 6] = 0.0 Matrix[ 7] = 0.0 Matrix[ 8] = 0.0 Matrix[ 9] = 0.0 Matrix[10] = -2.0/FMN Matrix[11] = 0.0 Matrix[12] = -((Right+Left)/RML) Matrix[13] = -((Top+Bottom)/TMB) Matrix[14] = -((Far+Near)/FMN) Matrix[15] = 1.0 End Function End Type -------------------------------------- CameraProject ProjectedX ProjectedY ProjectedZ Multiply the coordinates with the inverse transformation matrix of the camera and then multiply it with the viewmatrix of the camera. -------------------------------------- DeltaYaw / DeltaPitch: Calculate the worldcoords of the two entities and build a direction vector of it: V.X = Entity2.WorldX - Entity1.WorldX V.Y = Entity2.WorldY - Entity1.WorldY V.Z = Entity2.WorldZ - Entity.WorldZ Yaw = -ATan2(V.X, V.Z) Pitch = -ATan2(V.Y, Sqr(V.X*V.X + V.Z*V.Z)) -------------------------------------- GetMatElement: Calculate the global transformation matrix and then return the needed element of it. I hope, this will help you! Nice work! cu olli |
| ||
| Thanks Vertex! Hopefully I'll be able to add most of that to the next release. |
| ||
| Hi Simon, Excelent work! I do love this! I do have a question though- what are the chances of getting mouse/camera pick into this? :) |
| ||
| On my System(Debian GNU/Linux Sid) it works great! Excelent work! |
| ||
| Apparently MiniB3D programs bomb out on an Intel Mac - would someone with an Intel Mac confirm this for me please? Not sure why it would do that. |
| ||
| if someone doesnt get to it before i do, i can try this out for you tonight. |
| ||
it does crash. i tried test-anim and test-blend. both crashed on the same line inside of RenderWorld():Select ix Case 0 glActiveTexture(GL_TEXTURE0);glClientActiveTexture(GL_TEXTURE0) specifically it was the glActiveTexture() call. if i remember right, this is the same line it crashed on when i tried MiniB3D in linux so it may be more linux-intel related since MacOSX is linux based. dont have my laptop right now to try it out to make sure though. that crash was documented: http://www.blitzmax.com/Community/posts.php?topic=57783#665067 good luck and feel free to call on me to test it more. i think this is a very exciting addition to BMAX and want to help it grow as much as possible. keep up the great work! |
| ||
| I tried all examples and none crashed on my macbook pro. Could the crashes be limited to a certain model? PLS |
| ||
| Or on another tangent Could it be that gman has a Mac mini with the onboard Intel chipset and pls has the nvida card and the limitation with glActiveTexture is with the Intel/Mac Software implentation of this command. This is somewhat mitigated by the linux statement (FYI Mac OSX is not linux based but BSD Based. BSD is another unix variant). But it will be interesting to note if the crash occurs only on the cruddy onboard GPU's on the mac minis. Roger. |
| ||
| First: MiniB3D is a GREAT project! Thanks simonh. Maybe a check to see if glActiveTexture(), glClientActiveTexture() is supported would be in place? Shouldent there also be some kind of fallback if it is not? |
| ||
| the MacOSX crash was on a mini. also, the linux crash was using an ATI card in Xandros and i did confirm it was on the same line. |
| ||
| Thanks gman, that's a great help. I think glClientActiveTexture is probably the offending command as I believe that relies on an extension. Hopefully they'll be a way around it. |
| ||
| glad i could help :) i did break out that command and it was the glActiveTexture() that was crashing. it never made it to the glClientActiveTexture() call. |
| ||
| Great work! However, I can confirm that all test code that I tried on a Mac PPC G4, OSX 10.4.6, GeForce4 MX, crashes. Probably the same problem as others are reporting. Just wanted to report that it is also crashing on PPC Macs. I can offer this much. The crash occurs in TMesh.Update() and from what I can see it is glActiveTexture() and/or glClientActiveTexture() that crashes, as was mentioned above. Keep up the good work! |
| ||
| Just in case this helps. I checked, my card has 2 texture units. I tested the offending commands in a C++ program. They do not crash. It might indicate that there is a problem with the BlitzMax GL wrapper for MacOS X. |
| ||
| Here a little help with picking(I haven't test it)... CameraPick Camera, X, Y: Firstly, you render the entitys with pickmode polygon without lighting, textures and so one - the pure geometry - from the camera. Than you define the z value of the depthbuffer on x y: Y = ViewportHeight - Y Depth = glReadPixel(X, Y, 1, 1, GL_DEPTH_COMPONENT, GL_FLOAT) Now you can use gluUnproject to get the 3d coords. gluUnproject(Camera, X, Y, Depth, Modelview, Projection, Viewport, Varptr(PickedX), Varptr(PickedY), Varptr(PickedZ)) And the picked entity? Hmm... by rendering the entity, you can set the color of this to the handle(address) of it. With glReadPixel but with GL_RGBA you can get the picked color and so the picked address. I don't know, how to calculate a ray from X Y of the specfied camera. In the middle of the cameraviewport there is the ray Cameraposition + t*Cameradirection by t=>0. But you need this ray to get an intersection with spheres and cubes. Have anyone an idea to calculate the raystartposition by including X and Y? Maybe LinePick I can programm for you. cu olli |
| ||
| OK, I'm stumped - does anyone know why glActiveTexture is failing on some systems? |
| ||
| Just a quick question: Can MiniB3d do pixel-perfect lighting? The examples seem to be side by side comparisons with B3d, so I can't tell at first glance if there are any little goodies in here... Regarding glActiveTexture failing, I can't help you, but [a http://www.google.ca/search?q=glActiveTexture+fail&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official]I made a quick search just to be sure...[/a] My misguided guess tells me that it may be a combination of their OGL version and multitexturing? |
| ||
| Really good job simonh !! :) |
| ||
| No, the lighting is the same as B3D's - vertex lighting. I've already Googled glActiveTextures but nothing really comes up. This topic is near the top actually. |
| ||
| hi simon. could you whip up a minimal code example using that function? it would be nice to get it down to the basics for testing. |
| ||
| NOTICE: This workaround is not needed anymore! See below... I put this in a file "openglwrapper.c":
#include <OpenGL/gl.h>
int ActiveTexture(GLenum texUnit) {
glActiveTexture(texUnit);
}
int ClientActiveTexture(GLenum texUnit) {
glClientActiveTexture(texUnit);
}
I then stuck this at the top of "MiniB3D.bmx" Import "openglwrapper.c" Extern Function ActiveTexture(texUnit) Function ClientActiveTexture(texUnit) End Extern Finally I changed all occurences of glActiveTexture() and glClientActiveTexture() to call my wrapper: Select ix Case 0 ActiveTexture(GL_TEXTURE0); ClientActiveTexture(GL_TEXTURE0) Case 1 ActiveTexture(GL_TEXTURE1); ClientActiveTexture(GL_TEXTURE1) Case 2 ActiveTexture(GL_TEXTURE2); ClientActiveTexture(GL_TEXTURE2) Case 3 ActiveTexture(GL_TEXTURE3); ClientActiveTexture(GL_TEXTURE3) Case 4 ActiveTexture(GL_TEXTURE4); ClientActiveTexture(GL_TEXTURE4) Case 5 ActiveTexture(GL_TEXTURE5); ClientActiveTexture(GL_TEXTURE5) Case 6 ActiveTexture(GL_TEXTURE6); ClientActiveTexture(GL_TEXTURE6) Case 7 ActiveTexture(GL_TEXTURE7); ClientActiveTexture(GL_TEXTURE7) End Select The test code "test-anim.bmx" no longer crashes! This workaround seems to fix the crash, but I have not tested it carefully yet. Perhaps it helps anyway. Love Mini3D and will try to help out. We have experienced opengl programmers on our team, but I'm not one of them. Still learning. ;) |
| ||
| Never had a problem with glActiveTexture() or glClientActiveTexture(). Quick code tip? These 2 lines can replace the whole Select/End Select glActiveTexture GL_TEXTURE0+ix glClientActiveTexture GL_TEXTURE0+ix Good work on this project, looks like a lot of effort has gone into it. |
| ||
| How difficult would it be to add support for shaders. I would love to use this but really need normal maps and spec/spec masks. Is per pixel lighting something you can just switch on with a few ogl calls? |
| ||
| Also, any body know of a Mac 3d app that exports b3d meshes? |
| ||
| Can the people who are getting crashes try this out please: I suspect that those with the crashes won't have the ARB multitexture extension present, and hence the last line won't print. glActiveTexture was only added to the core of OpenGL in 1.3, and as Blitz uses OpenGL 1.1 (or 1.2, I forget), you have to use GlewInit in order to use the glActiveTexture extension. Possibly some newer machines don't have this extension. Thanks for the C test Jonas, at least that provides a workaround if all else fails! Jay - support for shaders probably wouldn't be too difficult, it's not something I really intend to implement though. Sorry! |
| ||
| i get: GL 1.2 ARB_multitexture present! this is an intel mac mini. |
| ||
| Only 1.2? I would have thought the new Mac Minis would be more up-to-date than that. I get 2.0 here on Windows. |
| ||
| gman - what about if you change glActiveTexture to glActiveTextureARB - don't suppose that fixes it? |
| ||
| unfortunately no :( EDIT: hold up. i put my debug lines back in. it is making it past those commands but crashing somewhere else. ill see if i can find it. EDIT2: success! changing _all_ references (duh) of glActiveTexture and glClientActiveTexture to the ARB version fixed the issue. it does have to be both glActiveTexture and glClientActiveTexture. |
| ||
| Yay! Cheers gman :) |
| ||
| glad i could help (didnt do much). i really want to see MiniB3D go all the way... as im sure many here do. on a side note, UltimateGameProgramming.com has several different mesh loader examples available in its OpenGL section. could be useful for anyone trying to expand MiniB3D with different mesh types. |
| ||
This is what I'm getting when running the test program:GL 1.1 ARB_multitexture present! Replacing all functions with _ARB works on my machine as well. Like gman I would really like to see an optimized MiniB3D as soon as possible, so just tell me if there is anything I can do to help out. Perhaps it should be a module with proper docs in the end? |
| ||
| >Jay - support for shaders probably wouldn't be too difficult, it's not something I really intend to implement though. Sorry! Thats OK, If its easy I'm sure someone else will give it a crack one day. I'm going to focus on actually making a game for a while. This is great work simonh. Cheers. |
| ||
| Yep. Had the same problem with Java + GL. Our program would fail on some systems due to us using non-ARB 2.0 core functions. So to be absolutely sure it works across all GL platforms, always use the ARB extension! Don't forget! |
| ||
the implementation design is a bit rough but still this is neat... at least IMO :) one of my favorite features of Irrlicht are its animators. animators are a way to encapsulate the control of entities via a type and let them control/handle themselves. it also allows for good code reuse. its kinda hard to grasp the full effect of what you can do with them. without any modifications to MiniB3D, here is a simple animator type. save this to a file called animator.bmx in the same directory as MiniB3D.bmx
' animator.bmx
Type IEntityAnimator Extends TMesh
Method Update()
Local entity:TEntity=GetParent()
If entity Then AnimateEntity(entity,MilliSecs()) Else DebugLog("IEntityAnimator: No Entity")
EndMethod
' called each update to animate an entity
Method AnimateEntity(entity:TEntity,timeMS:Int) Abstract
EndType
now for an implementation. this is based on the MiniB3D test-alpha.bmx program. save the following code into test-alpha_anim.bmx in the same directory as test-alpha.bmx
Import "../MiniB3D.bmx"
Include "../animator.bmx"
Local width=640,height=480,depth=16,mode=0
Graphics3D width,height,depth,mode
Local cam=CreateCamera()
Local light=CreateLight()
Local ent1=CreateCube()
Local tex=LoadTexture("media/test.png")
EntityTexture ent1,tex
Local ent2=CopyEntity(ent1)
Local ent3=CopyEntity(ent1)
Local ent4=CopyEntity(ent1)
Local ent5=CopyEntity(ent1)
Local ent6=CopyEntity(ent1)
' -----------------------------
' add a controller to the cam. this could just as easily
' be added to one of the cubes
' -----------------------------
TCameraController.EntityAddAnimator(cam,0)
' -----------------------------
' -----------------------------
' create simple rotation animators and add them to
' ents 1-4
' -----------------------------
TSimpleRotateAnimator.EntityAddAnimator(ent1,.5)
TSimpleRotateAnimator.EntityAddAnimator(ent2,-.5)
TSimpleRotateAnimator.EntityAddAnimator(ent3,1)
TSimpleRotateAnimator.EntityAddAnimator(ent4,-1)
' -----------------------------
PositionEntity ent1,0,0,10
PositionEntity ent2,0,0,5
PositionEntity ent3,0,0,20
PositionEntity ent4,0,0,15
PositionEntity ent5,0,0,30
PositionEntity ent6,0,0,25
EntityAlpha ent2,0.5
EntityAlpha ent4,0.5
Local cx#=0
Local cy#=0
Local cz#=0
Local pitch#=0
Local yaw#=0
Local roll#=0
' used by fps code
Local old_ms=MilliSecs()
Local renders
Local fps
While Not KeyDown(KEY_ESCAPE)
If KeyHit(KEY_ENTER) Then DebugStop
RenderWorld
renders=renders+1
' calculate fps
If MilliSecs()-old_ms>=1000
old_ms=MilliSecs()
fps=renders
renders=0
EndIf
GLDrawText "FPS: "+String(fps),0,0
Flip
Wend
End
' -----------------------------
' begin the animator types
' -----------------------------
' conrols a camera (or potentially any entity) via keyboard
' arrows UP/DOWN/LEFT/RIGHT and keys W/A/S/D
Type TCameraController Extends IEntityAnimator
Field cx#=0
Field cy#=0
Field cz#=0
Field pitch#=0
Field yaw#=0
Field roll#=0
Method AnimateEntity(entity:TEntity,timeMS:Int)
' control camera
If KeyDown(KEY_UP) Then cz#=cz#+1.0
If KeyDown(KEY_LEFT) Then cx#=cx#-1.0
If KeyDown(KEY_RIGHT) Then cx#=cx#+1.0
If KeyDown(KEY_DOWN) Then cz#=cz#-1.0
If KeyDown(KEY_W) Then pitch#=pitch#-1.0
If KeyDown(KEY_A) Then yaw#=yaw#+1.0
If KeyDown(KEY_S) Then pitch#=pitch#+1.0
If KeyDown(KEY_D) Then yaw#=yaw#-1.0
entity.MoveEntity(cx#*0.5,cy#*0.5,cz#*0.5)
entity.RotateEntity(pitch#,yaw#,roll#)
cx#=0
cy#=0
cz#=0
EndMethod
Function EntityAddAnimator(entity:TEntity,order:Int=0)
Local anim:TCameraController=TCameraController.Create(entity)
' set the order so the animator update is called before the update to the entity
EntityOrder(anim,(999999-order))
EndFunction
Function create:TCameraController(parent_ent:TEntity)
Local piv:TCameraController=New TCameraController
piv.class$="TCameraController"
piv.AddParent(parent_ent)
piv.EntityListAdd(entity_list)
' update matrix
If piv.parent<>Null
piv.mat.Overwrite(piv.parent.mat)
piv.UpdateMat()
Else
piv.UpdateMat(True)
EndIf
Return piv
EndFunction
EndType
Type TSimpleRotateAnimator Extends IEntityAnimator
Field rate:Float
Method AnimateEntity(entity:TEntity,timeMS:Int)
entity.TurnEntity(0,rate,0)
EndMethod
Function EntityAddAnimator(entity:TEntity,rate:Float,order:Int=0)
Local anim:TSimpleRotateAnimator=TSimpleRotateAnimator.Create(entity)
anim.rate=rate
' set the order so the animator update is called before the update to the entity
EntityOrder(anim,(999999-order))
EndFunction
Function create:TSimpleRotateAnimator(parent_ent:TEntity)
Local piv:TSimpleRotateAnimator=New TSimpleRotateAnimator
piv.class$="TSimpleRotateAnimator"
piv.AddParent(parent_ent)
piv.EntityListAdd(entity_list)
' update matrix
If piv.parent<>Null
piv.mat.Overwrite(piv.parent.mat)
piv.UpdateMat()
Else
piv.UpdateMat(True)
EndIf
Return piv
EndFunction
EndType
' -----------------------------
' -----------------------------
i have created two very simple animators. one is a camera controller. it shifts the key checking and manipulation based on input to the animator instead of the game loop. one nice thing about using an animator for this, is instead of attaching the animator to a camera, you could just as easily attach it to a cube, or any entity for that matter and get the same control features. the second animator is a simple rotation animator. it turns an entity based on the passed in rate. you can see i use instances of the same animator type with different rates for different cubes. notice with animators there are no calls in the game loop. the engine handles that because its already calling the Update() on the animators. these are very simple animators but the uses are endless. following cameras, circling entities, AI, waypointing. in Irrlicht i have currently implemented a decal entity class. i use an animator to continually place the decal under an entity to give sort of a selected RTS unit effect. i just place the animator and forget about it. cool stuff. enjoy :) EDIT: forgot to say another big THANK YOU to simonh. MiniB3D is very cool. another thing i realized the other day is that there are probably a ton of routines in the code archives that are usable with MiniB3D! |
| ||
| I'd be very intrested to hear other peoples experience at optimising minib3d. I've used the BirdDemo to experiment as it seems a simple "real world" example. Unfortunatly I've not been able to give it much time, but I have discovered that actually drawing a mesh isnt the main bottle neck! I've looked at using hires timers and its actually easier than you'd think (at least on win32), if anyone is activly working on optimising minib3d and would find this useful, pleas do contact me. |
| ||
| @Chris - comment out the two calls to SetAnimTime and it cruises. without looking deeper id say the problem is somewhere in there... probably the AnimateMesh function. EDIT: SetAnimTime is definately the culprit. B3D it bounces between 0 and 2 millisecs per call, for MiniB3D it ranged between 13 and 21 millisecs. EDIT2: a little more info... it takes 1 or 2 millisecs per bone in the mesh. there are 10 bones per bird. |
| ||
| V0.2 is out-of-date now, the current version V0.3 is quite a bit faster. I'll upload V0.3 shortly. Thanks for the suggestions gman (post + email). Quite a lot to digest but I'll see what I can do :) |
| ||
| very much looking forward to the new version! and you are very welcome. have a few more ill send your way as well :) |
| ||
| I look forward to 0.3 :-) |
| ||
| good job simonh! It's Great! I like to see the next versions ;) |
| ||
| blitz3d command set for max how cool, looking foward to version 0.3 here also. one thing though for the complete newbie to opengl what would be the best way to implement the collision commands. i would like to take a go at this any links / tutorials to set me in the right direction? thanks again simonh for the hard work you put into this. kev |
| ||
| Collision commands would not be particularly easy to add - you would need to try and integrate a 3rd party lib like Coldet or Opcode, or add your own intesection routines which you could Google for. And that would be just for detecting collisions - acting upon them (i.e. sliding collisions) is another beast altogether. Best bet is to just use Viper's ODE mod with this. |
| ||
| For sliding you can make a search for : < General collision detection for games using ellipsoids > this will solve your character movement. I made a test for 2D and it's working great. http://www.blitzmax.com/Community/posts.php?topic=55799 It will be good to warn you that you will need to learn more things to make it usable. Like how to reduce the planes that you have to check for collision and much more. I agree with simonh a good cross platform wrapper of coldet or Opcode or Bullet will be make your life easier ( but we don't have any ) |
| ||
| General collision detection for games using ellipsoids No, that doesn't work in 3D, at least not fully. Mark tried implementing it when B3D was still in beta (after I pointed him towards it), and he found out it had some flaws in it. That's why the document is now listed as 'deprecated' on the www.fluidstudios.com site. |
| ||
| I just learned what means 'deprecated'... I hope that someone will make a wrapper of any collision detection lib cause the field it's to hard and not funny at all. By the way a win32 wrapper of coldet it's out there by Noel. |
| ||
| I'm having problems with MiniB3D on my laptop. I get a "Unhandled Exception: Unhandled Memory Exception Error" I tried the .c patch above, but can't seem to get it to compile on my system. The test program above prints out GL 1.1 ARB_multitexture present! Laptop Specs are Gateway MX3225; Intel Celeron M 370; Windows XP Home sp2; 256 MB DDR2; Video S3 Graphics UniCHrome Pro IGP; 64MB shared video ram; DirectX 9.0c |
| ||
| @TomToad - try changing all references of glActiveTexture and glClientActiveTexture in MiniB3D.bmx to glActiveTextureARB and glClientActiveTextureARB. |
| ||
| That worked. Thanks gman. :) |
| ||
| I'm a bit of a BMX newbie so sorry for asking this question, but would the speed of MiniB3D significantly improve if it was written in C++ and wrapped into BMX? Loading models at least with v 0.2 is too slow to be workable. The loader might benefit from being ported to C++. The downside is that many BMX users, that do not know C++, wouldn't be able to mod the source. |
| ||
| There might be a slight speed increase, but I'd doubt if it would be significantly large. Most likely the slowdown comes from unoptomised code. Did you see where he mentioned that he'll be releasing v0.3 soon which is supposed to be much faster? V0.2 is out-of-date now, the current version V0.3 is quite a bit faster. I'll upload V0.3 shortly. Thanks for the suggestions gman (post + email). Quite a lot to digest but I'll see what I can do :) Si. |
| ||
| Not sure they'll be much of a speed increase in loading models in the new version. That's pretty much as fast as it can be. With debug off it should be OK, with debug on unfortunately that's where you get the slow down. C++ would probably be faster. |
| ||
| Si - I've not looked at this at all so apologies if you've already done this - you could amend all your functions / methods to use "NoDebug", this would improve matters for debug mode performance. |
| ||
| @TomToad: Yes, I noticed Simon's post. Thanks, anyhow, it is easy to miss in such a long thread. @simonh: Thanks for the info. Turning debug off makes a lot of difference, but loading a dwarf warrior (medium complex model) still takes about 35 seconds (on my 1 GHz G4), so any optimization is welcome. ;) When v 0.3 is released I can take a look at loading. Free dwarf model came from: http://www.psionic3d.co.uk I'm quite new to BMX, but I'm at least an intermediate level C/C++ programmer. It is my impression that wrapping in C/C++ code often pays off. BMX has some overhead that can sometimes slow things down. |
| ||
| Wrapping C/C++ should not make it noticable faster. Loading the file into memory and parsing it there would give a major speedup. Looking forward to v0.3 :) |
| ||
| I had a play with an opengl profiler, it looks like the gpu is only active 50% of the time, with vertial sync on, so I guess the cpu is holding things up with more calculations that actually needed. I'm guessing that replacing non animated surfaces's with a call list, and animated mesh's with an arrays of surface call lists, would probably have the most noticable speed increase. What do people think would be the best way to handle camera frustum culling? Has anyone spotted places where matirx calculations could be cached between frames. |
| ||
| Si - I've not looked at this at all so apologies if you've already done this - you could amend all your functions / methods to use "NoDebug", this would improve matters for debug mode performance. I wasn't aware you could do that - thanks for the tip! Thanks for the info. Turning debug off makes a lot of difference, but loading a dwarf warrior (medium complex model) still takes about 35 seconds (on my 1 GHz G4), so any optimization is welcome. ;) 35 seconds sounds like an insanely long time! Even with debug mode on, it takes 1 second at most here and I only have a 1.7Ghz CPU. Did you mean 3-5 seconds perhaps? (I hope!). Loading the file into memory and parsing it there would give a major speedup It would? I'll have to try that, thanks. What do people think would be the best way to handle camera frustum culling A camera culling system exists in 0.3, using bounding spheres. It works fairly well, although I really need to change it to bounding boxes (which is what B3D does). |
| ||
| 35 seconds sounds like an insanely long time! Even with debug mode on, it takes 1 second at most here and I only have a 1.7Ghz CPU. Did you mean 3-5 seconds perhaps? (I hope!). Nope, I clocked it using MilliSecs(). Using the "test-anim.bmx" code I loaded the "dwarf2.b3d" model from psionic3d. With debug build on it clocks in at 83 seconds and with debug turned off it clocks in at 36 seconds. That is why I'm whining about it. ;) Started to port my game (Darkwynd) as a test, but launching takes such a long time that it is not possible to work with at the moment. Wrapping C/C++ should not make it noticable faster. Not sure what you mean here! It is clear that just porting the code that reads from the file wouldn't help much. It is the processing of the model data that needs to be ported. Although, if BMX file functions actually doesn't read the whole file into memory, what you suggest might explain why it is so slow and fixing that might of course suffice. |
| ||
| There's no way it should be taking that long. Sounds like something is amiss somewhere. |
| ||
| Hey All, This weekend i put together a simple shooter and ran into a strange problem in MiniB3D. Very intermittently ( perhaps 1 in 100 times) when calling FreeEntity, the game would crash while attempting to access a null object. I narrowed this down to the line that uses the link to remove the entity from the list of all entities. I fixed the crash by removing the object from the list rather than using the link. For example, this works TEntity.entity_list.Remove (Self.Mesh) but this creates the intermittent crash Self.Mesh.Link.Remove() Does anybody know the difference between the two? It is possible that I'm calling this twice on an object, would Link.Remove crash but List.Remove work if the object was already removed from the list? |
| ||
| Really looking forward to 0.3, I'm using this as a temporary (or maybe not) engine for my next game. Jay - Yes, List.Remove doesn't give an error if the object isn't found on the list, but Link.Remove will probably crash if called twice in a row. |
| ||
| This type of error sounds like list.reverse was used somewhere. BMs original implementation of list.reverse does not keep the links alive. This problem was spotted by Sswift long ago and I provided a "link stable" version of reverse that solves the problem. And List.remove will always work. But it just won't do anything beside looping through the list till it realizes that the object isn't there. With link.remove it tries to remove one specific instance which must be there to be removed. |
| ||
| Thanks for the notes guys. I was doing some more profiling of my game to work out what was so slow and discovered that even PositionEntity is taking about half a millisecond per call on test cubes. In my shooter with roughly 40 objects moving each frame, the entity update was taking about 20 ms where as the render call was only around 5. |
| ||
| Yes the main bottleneck is the matrix commands in 0.2, which means all the movement commands are slow. list.reverse isn't used anywhere, the link error is down to an error in the MiniB3D code (now fixed). |
| ||
| There's no way it should be taking that long. Sounds like something is amiss somewhere. I clocked it on my WinXP machine (1.8 GHz) as well. It takes 10 seconds to load with debug off. There is a lot of animations in this model. Perhaps that is what takes time to parse. I get about 60 FPS though, dispite having just a crappy Mobile Intel graphics card. |
| ||
| Thread 2 |
   |