miniB3D - part 2
Monkey Forums/User Modules/miniB3D - part 2
| ||
Continued from here. By AdamRedwoods: Last post from previous thread by visionastral: I noticed something weird: In your examples, this line is making the app crash 50% of the time: txt.SetText(fps+" fps ~nhow are you",0,0) I have noticed it's because of the "~n" new line character. If I delete it, then it never crashes. That's very weird, specially because it doesn't crash every time, but only 50% of the times or so... Perhaps it has something to do with the fps counter, I don't know. - edit: By the way, I'm compiling for GLFW when this happens - |
| ||
minib3d+monkey https://github.com/adamredwoods/minib3d-monkey branch: v0.20 requires most recent Monkey big note: - turn on config.h depth_buffer_bits = 32 (not needed in v0.20) - tested on glfw, android, macos, ios Works! - normals work - textures, mipmaps work - android, works - vbos and non-vbo fallback works - sprites - batch sprites - context handling for mobile devices - pick (optimized) - collisions - binary load for b3d files (base64) - animation, bone & vertex - Load OBJ - animated textures To Do: - XNA target - WebGL target - shaders - MDD/3DS loaders ![]() ![]() |
| ||
I noticed something weird: In your examples, this line is making the app crash 50% of the time: txt.SetText(fps+" fps ~nhow are you",0,0) I have noticed it's because of the "~n" new line character. If I delete it, then it never crashes. That's very weird, specially because it doesn't crash every time, but only 50% of the times or so... Perhaps it has something to do with the fps counter, I don't know. - edit: By the way, I'm compiling for GLFW when this happens - Ok, I will check it. I know there were some bugs with that in earlier versions, but I thought the latest version fixed it. |
| ||
Bug found in TFormPoint function (tentity.monkey) TFormPoint is using FastRotateScale to perform matrix operations, but it seems FastRotateScale is not working as expected because I had to disable it and enable the commented out functions Scale,RotateRoll,Pitch... in order to make it work. Something is really wrong with FastRotateScale (matrix.monkey) and will make bugs if it's used anywhere else. (as I suppose is the case) By the way, in the SetText function, you are using "cam" as the camera the text object is being aligned to. However, this variable is not defined anywhere in MiniB3D except in the examples, throwing a memory handle error when compiling if your app hasn't created this variable as a global and as a camera. The FastRotateScale bug was driving me really crazy for 3 days! But now I'm making some shadow mapping on monkey with miniB3D! :D I just love the Blitz community! ^_^ -EDIT- Another little bug: In the BackBufferToTex method (ttexture.monkey) the OpenGL bit format is incorrect. It's not GL_RGBA8888 but GL_RGB: (if you use GL_RGBA it will not work on Android, as the color buffer does not have alpha information.) glCopyTexImage2D(GL_TEXTURE_2D,mipmap_no,GL_RGB,x,TRender.height-y-height,width,height,0) |
| ||
Mmmm... That's weird but when I compile for android, any change I make to a texture isn't updated on screen. That's not happening when I compile for GLFW. I mean, I'm rendering the scene with RenderWorld, then I copy the render to a texture with BackBufferToTex. At this point, the texture is already updated on GLFW, but on Android, the texture is still in the same state as when it was created (full black) and doesn't want to be updated. I have tried using TTexture.BindAnimTexture(texture,flags) but the texture goes wrong in both targets if I make this (becomes full black) and on android it drops framerate from 60fps to 6 ! Any help will be very welcome! -EDIT: - Ok, if I use BindAnimTextures, it is reloading the texture from RAM to the texture memory, that's why it's slow. But the fact is BackBufferToTex is supposed to copy the color buffer from opengl (the output default buffer) to a texture INSIDE the graphic memory, thus making it very fast. And that's what it makes in my PC when I compile to GLFW, but it's not happening on Android... Is this a limitation of OpenGLes 1.1 on Android?? If this is the case, I will need to switch to GLES2.0 quickly.... |
| ||
-THIS HAS BEEN SOLVED CHANGING THE BIT FORMAT OF glCopyTexImage2D TO GL_RGB instead of GL_RGBA - After googling a lot, I deduced some GLES stuff about Android: It seems Android only supports OpenGLes 1.0 and OpenGLes 2.0 (Android v2.2), so the problem is OpenGLes 1.0 is NOT OpenGLes 1.1, and one of the big differences was the addition of Frame Buffer Objects for doing exactly what I'm doing. Sooo... I will need to switch to OpenGL 2.0 no matter what. Adam, you seem to plan to "officially" support OpenGL 2.0. I'm not really in a hurry to switch, since I can work on GLES11 on my PC and I have lots of stuff to do (starting with my shadow mapping module) but I just want to know the place GLES20 has in your todo list for MiniB3D. (or if you don't plan to make it any time soon.) (I really don't mean to rush anyone and don't expect others to program anything specially for me. It's just to know if I will have to do GLES2.0 support by myself (given the fact I'm a total noob on OpenGL! :p )) |
| ||
Re:TFormPoint Sorry about that, yeah, there are residual bugs left over from attempts to optimize the matrices. Matrix.FastRotateScale() overwrites itself and does not take into account the prior matrix (which is why its faster). I use it only on the local matrix, not on global matrices. TFormPoint() uses global information by looping over the entity hierarchy. This isn't needed as I am storing global matrices and global scale. This routine may be faster: minib3d/tentity/TFormPoint Function TFormPoint(x#,y#,z#,src_ent:TEntity,dest_ent:TEntity) 'Local mat:Matrix=global_mat.Copy() '***global*** temp_mat.Overwrite(global_mat) If src_ent<>Null temp_mat.Overwrite(src_ent.mat) temp_mat.Translate(x,y,-z) x=temp_mat.grid[3][0] y=temp_mat.grid[3][1] z=-temp_mat.grid[3][2] Endif If dest_ent<>Null temp_mat = dest_ent.mat.Inverse() temp_mat.Scale(1.0/(dest_ent.gsx*dest_ent.gsx), 1.0/(dest_ent.gsy*dest_ent.gsy), 1.0/(dest_ent.gsz*dest_ent.gsz)) temp_mat.Translate(x,y,-z) x=temp_mat.grid[3][0] y=temp_mat.grid[3][1] z=-temp_mat.grid[3][2] Endif tformed_x=x tformed_y=y tformed_z=z End |
| ||
Re:SetText By the way, in the SetText function, you are using "cam" as the camera the text object is being aligned to. Yes, you need to assign the camera being used to TText or it will not work, since I need to do a camera Unproject. (will probably fix this so it's not needed in the next version). Re: BackBufferToTex Ok, thanks for finding this bug! |
| ||
Re:BackBufferToTex I threw this in there with no testing :D. Ok, so GLES1.1 is not guaranteed on all Android devices, so there will be limitations. I'll test it on my end. http://stackoverflow.com/questions/1781371/android-glcopyteximage2d-any-success Re: minib3d+monkey GLES2.0 I don't want to get ahead of myself, but this is in progress and moving along! This will be a big update with many changes (under the hood, API stays the same). |
| ||
OOOK! I found the issue! I changed the bit format of glCopyTexImage2D to GL_RGBA instead of GL_RGB ! Now since the color buffer does not store alpha information, it raises an error on android and doesn't work (raises an internal error that doesn't stop your app, that is). I have fixed the earlier posts to simplify the life of the people who search the forums for answers (like I do a lot). Now shadow mapping is working at 60fps on android! :D Still a very early function, but I plan to make it a stand alone module as easy to use as "set shadow caster" and "set shadow receiver". About GLES2.0: I'm really really REALLY happy you're working on it! Pixel shaders are one of those things I wanted to make a loong ago but never found the courage to learn visual c + openGL! (I even studied the pixel shader programs to know how to do stuff like parallax mapping and the like) Having Blitz3D with pixel shaders has been my geek's wet dream for years! Now, don't rush! Take your time and do it right! ;) |
| ||
This routine may be faster It is! Thank you very much! (and it works ;) ) By the way, if there is any other way to make this calculations faster it would be very welcome, since the shadow mapping technique relies massively in this matrix transformations to do the trick. It's not slow now, but it can slow down pretty quickly with shadows depending onto how much poligons the shadow is being projected. (obviously, I'm talking about android now. In GLFW you have light speed those days!) |
| ||
GLES 2.0 in progress: 100 zombies with per-pixel lighting it's a work in progress seeing how the frame rate is low. ![]() |
| ||
GO! GO! GO! :D |
| ||
per-pixel lighting ! THAT's what I need! :D (well, I will be needing everything cool you'll show anyway :P ) |
| ||
Another bug found! PC and MAC platforms are veeery permisive with parameters in OpenGL, but android isn't. The fog rgb information must be given as an array of 4 instead of 3, otherwise, it will crash anytime you want to activate the fog. change line 523 in "tcamera.monkey": Local rgb#[]=[fog_r,fog_g,fog_b,0] This will fix it. I suppose other errors like this one are to be expected, so we will have to watch for them! |
| ||
I suppose other errors like this one are to be expected, so we will have to watch for them! yes, thank you! Do you know if "0" fixes it or should it be "1.0", as this is fog I'm not sure what it's alpha should be, or if it's ignored. |
| ||
I was asking myself the same question... xD I have tried it with 0 and worked ok, but since I'm not really doing fog in a regular render way, I can't really say. In fact, I was using the fog as a way to enlighten shadow mapping internal renders, and it's working (making parametric transparent shadows) so it should be ok. Anyway, putting a 1.0 instead of a 0 should be wiser... just in case other phone's opengl don't like a zero there (or iphone's?). By the way, I was thinking you could include my shadow mapping engine into MiniB3D once it has been finished. It's pretty straigth forward and should work in GLES20 without any modification, since the shadows are made of poligons with transparent maps on them. You use it simply calling "New ShadowMappingCaster(cube)" for a cube to cast shadows, and define receptors and light emitters the same way. The shadows are update and rendered in the same function just before RenderWorld. I'm optimizing as much as I can without entering too much inside the MiniB3D internal work, but I think it could be much more fast if we simply put it into the render pipeline with straight opengl commands. Right now it's extremely fast in PC, but I'm much more concerned by android devices. I'm planning to do a "fake" shadow option for alowing objects to cast circular shadows to the ground under them. It should be much better suited for small devices than full projected shadows and you could swap them just switching a boolean. |
| ||
-edit: I found the answer, nevermind- |
| ||
Re: shadows yes, great contribution. are you creating shadow volumes or shadow maps? re: adding to minib3d yes, but i need to present v0.2 (opengles20) which is a redesigned render system, which allows additions like this. I need to create a new branch/fork on github for this, but i'm not sure how to do this? i could do this early (it would be incomplete), to allow you to work with it. i would just want to make sure people wouldn't expect it to be finalized. It's pretty sweet, the underlying API is the same, but the opengl20 stuff is very flexible, allows for FrameBuffers and multiple shaders. |
| ||
I'm making shadow maps, not volumes. (I will surely make an stencil shadow engine for gles20 later. It will be better suited for interiors) The shadow maps are projected rendered shapes of the caster object mapped on poligons wich mimics the receivers surface. This is done individually for each emitter/caster/receiver and generates individual geometries parented to the receiver object. This means you don't have to update all the shadows at once but only those that had been changed (this will be done automatically). It's well suited for exterior lighting and for faking simplistic shadows under enemies ie. However, interior results are somewhat poor compared with stencil buffer techniques because the individual shadow maps overlap each other and gives a weird sensation. But with opengles 1.1 you can't do better for the price ;) And stencil shadows are too much expensive in ressources for exterior lighting even on pc. |
| ||
Another idea for gles20 is the shadow mapping technique used in ps3 and xbox: a global shadow map for each light with zbuffer. Then you have to filter wich pixels will be shadowed with a pixel shader, comparing the pixel's z position (in the light's matrix) with the zbuffer of the shadowmap. The good thing with this technique is: it's fast and convenient, but the resolution of the shadowmap quickly becomes a problem since it will be projected and thus pixelate a lot. A good game to see this technique in action is devil may cry 4. |
| ||
Adam, could it be done to use OpenGL to perform matrix operations for calculating the transformation of a given point/vector just like the TFormPoint and TFormVector functions? I think it would greatly improve shadows performance in android, because right now I'm making the calculations at the CPU, and using GL it would be done by the GPU, wich seems much better suited for that stuff. Excuse me but I'm a noob with OGL :P |
| ||
re:opengl matrix math you can offload math to the gfx chip, but some people would argue that transferring the data to the chip and back would be slow enough that it may be better to do it with the cpu. you'd have to do some speed tests. it definitely would work better in gles2.0. |
| ||
** UPDATE v0.20 ** I have now created a new alpha-stage branch "minib3d.2.0" which encapsulates all the driver specific routines. the API should be the same, but the underlying code is different. Overall, this will allow targets to be made for almost every platform since only ONE file needs to be changed and updated for a target (for the most part). New targets need just extend TRender and fill in the appropriate methods. If anyone is up for an XNA/DirectX target, feel free. Needs at least monkey56. ** OpenGLES2.0 and WebGL ** I haven't added that in yet, but it is working. I want to make a dramatic announcement for that, since it is a big deal, so I am working on some cool examples with shaders and all. Plus, opengles2.0 will not work until Mark fixes a few errors with the webgl target, so it will require the LATEST monkey version. |
| ||
opengles 2.0 currently works for android and glfw? (I don't care of webgl right now :P ) |
| ||
Great work Adam, looking forward to having a play with this. |
| ||
Really looking forward to WebGL. Great stuff Adam. |
| ||
you're my hero Adam! |
| ||
100 zombies. WebGL in firefox on the left, opengles11 on the right. getting closer. rebuilding the fixed function is a pain! Note the wrong light direction on the red ball. ![]() |
| ||
note the per pixel lighting on the left ;) You're doing an awesome work there Adam. You're earning so much good karma with that you will eventually levitate in bliss and joy. (surrounded by red balls hating zombies) |
| ||
Well I dropped Monkey after I realised that a good 3D lib was not on the horizon, this has brought me back. Thank you Adam. |
| ||
Hi Guy's wow this is exciting for old Blitz3d user getting an error though when compiling to android on the phone it say's Monkey runtime error:unable to parse '0-CM' as integer...C:/aaamonkeey/MonkeyPro56/modules/minib3d/trender.monkey Donno why any ideas lee |
| ||
a bug! thanks. change opengles11.monkey (trender.monkey-- old version) Method GetVersion:Float() Local s:String[] = glGetString(GL_VERSION).Split(".") If s[0].Length() > 2 Local st:String[] = s[0].Split(" ") s[0] = st[2] Endif Local len:Float = 1.0/(10*s[1].Length()) Return Float( Int(s[0])+Int(s[1])*len ) End i'll update github. **FYI** just so you know, there's a branched version (v0.20) that is more up-to-date and will be more in-line to the next big update. |
| ||
Hi Adam Changed this in the trender.monkey still get the same error will try the forked version(v0.20) now Thanks For you Help...really excited to use Blitz3d again lee |
| ||
brute-force approach for non-compliant version numbers:Method GetVersion:Float() Local st:String Local s:String = glGetString(GL_VERSION) Local num:Int=0 For Local i:Int=0 To s.Length()-1 If (s[i] >47 And s[i]<58) st=st+String.FromChar(s[i]) If num =0 Then num=1 Elseif s[i]=46 If num=2 Then Exit st=st+String.FromChar(s[i]) num=2 Elseif num<>0 Exit Endif Next Return Float( st ) End |
| ||
Hi Adam Got it Working its Fan Daby Dozzy Awsome... i changed get version in opengles11.monkey(AS Above) from branched version (v0.20) then i was getting error: C:/aaamonkeey/MonkeyPro56/modules/minib3d/tsurface.monkey<140> : Identifier 'tex_frame' not found. Monkey runtime error: C:/aaamonkeey/MonkeyPro56/modules/minib3d/tsurface.monkey<140> : Identifier 'tex_frame' not found. i commented out this line in tsurface.monkey.... line 140..brush.tex_frame = bru.tex_frame then i was getting error: C:/aaamonkeey/MonkeyPro56/modules/minib3d/tbrush.monkey<206> : Identifier 'tex_frame' not found. Monkey runtime error: C:/aaamonkeey/MonkeyPro56/modules/minib3d/tbrush.monkey<206> : Identifier 'tex_frame' not found. i commented out this line in tbrush.monkey.... line 206...'If brush1.tex_frame<>brush2.tex_frame Then Return False ''may not want if animtextures have different start frames Thanks Soo Much for this Adam coding coding coding lee |
| ||
i commented out this line in tsurface.monkey.... ya, sorry, i did move tex_frames around. removing that is ok. In other news... [monkeycode] Class MyShader Extends TShaderGLSL Implements TShaderRender Field fbo:FrameBuffer Method New() 'Override(1) ''override brush shaders AddProcess(Self) SetShader(Self) fbo = FrameBuffer.CreateFBO(CreateTexture(256,256,3)) Print "yes" End Method PreProcess() Print 123 End Method PostProcess() Print 456 End Method Render(cam:TCamera) fbo.BeginFBO() DefaultShader() RenderCamera(cam) fbo.EndFBO() DefaultShader() fbo.Display() End End [/monkeycode] The above code is an example of the *custom* shader pipeline. SO far, so good! FBO's and shader swapping works on html5,glfw,android. |
| ||
Adam, WE ARE WATCHING YOU xD This will be a major upgrade for monkey, keep up the awesome work! :) |
| ||
Not having much luck with this. Just installed the latest version of Monkey (v58) along with a fresh install of VCPP Express specifically to have a jolly faff about with it (Oooh! MiniB3D in Monkey! etc) but I initially got some similar errors to LeeTheGee1 (except his fixes above didn't work for me). Reset my PC (which I hadn't done after installing VCPP Express) and took a fresh take on both forks, and got the following errors (all with GLFW as the target)...0.14 (df70f5de41) ================= ttexture.monkey > Compile Error, Identifier 'MINIB3D_DRIVER' not found. Branch (559cf932dc) =================== animation_test pick_collision_test trender.monkey > Compile Error, Line 215, Unable to find overload for Update(). firepaint3d ttexture.monkey > Compile Error, Line 613, Identifier 'DeleteTexture' not found. Dunno if this helps or whether I'm being thick and have missed something obvious, but there you go. |
| ||
took a fresh take on both forks, and got the following errors OK, my fault since I am messing up maintaining these two branches. Best to stick with v0.20. The Branch errors you're getting seem to be mixing v0.14 and v0.20. I'd delete the minib3d module and start with just v0.20. |
| ||
Oh I cleaned out 0.14 before trying 0.20 -- there's nothing persistent beyond the module folder is there? |
| ||
ok. i double-checked against monkey58/trans v1.34, and works here. trender.monkey > error line 215, I can't find a line with Update() (v0.20), but that line is in the old trender.monkey (v0.14). This is why I thought v0.14 and v0.20 were swapped. ttexture.monnkey > error line 613, DeleteTexture was moved to TRender.render (in v0.20), so the render object must be defined before this works. A sure way to force this is to put Import minib3d.opengles11 at the top (before other imports) of the example program. Also, when compiling (minib3d v0.20), the output should show which driver is being used: Translating firepaint3d C:/Monkey/bin/trans_winnt -target=mingw -run D:/_work/software_dev/_monkey/bananas/minib3d_bug_testing/firepaint3d.monkey TRANS monkey compiler V1.34 Parsing... MINIB3D_DRIVER=default default being opengles11. Try again, delete the build folder too. Check trender.monkey source and verify that #MINIB3D_DRIVER is in there (v0.20). |
| ||
Ah, I just deleted trender, compiled and up it popped again as if it were still there. Made me look suspiciously at Windows 7 and, a quick search later, I find "C:\Users\Sledge\AppData\Local\VirtualStore\Program Files\Monkey\modules\minib3d"! So yep, the OS had been kindly mixing and matching any edits & file deletions -- I'm back to the errors that LeeTheGee1 had now so fingers crossed... |
| ||
Righto. Fresh version of v0.20, previous build folders deleted, virtual files zapped and I'm running Monk as admin so it shouldn't bother me with that sort of silliness again. I get the same error as LeeTheGee1 reported at first... Monkey runtime error: C:/aaamonkeey/MonkeyPro56/modules/minib3d/tsurface.monkey<140> : Identifier 'tex_frame' not found. ...but when I comment out line 140 the build process fails... It definitely can build for GLFW as I tried the clock demo and it ran fine... stumped! |
| ||
That error is something that MR. MARK SIBLY needs to fix.... *AHEM, AHEM* We've mentioned it before, along with a slew of webgl fixes. in modules/opengl/native/databuffers.cpp change ~DataBuffer to look like this: ~DataBuffer(){ if( _data) free( _data ); } |
| ||
That did the trick! Excellent stuff -- that's my weekend gone! |
| ||
Hi All Thanks to everybody in this forum i think i am off and running...i have attached a simple 3d collision example that may be helpful to others..with some help from here http://www.blitzbasic.com/Community/posts.php?topic=97932...not monkey specific 'Strict '..........think this is important #TEXT_FILES="*.txt|*.xml|*.json|*.obj|*.mtl" Import mojo Import minib3d Function Main() New Game End Class Game Extends App Field cam:TCamera Field light:TLight Field txt:TText Field cube:TMesh Field cube2:TMesh 'Global noise:Sound ' used by fps code Field old_ms:Int Field renders:Int Field fps:Int Field a:Float=0, dir:Int=0, oldTouchX:Int, oldTouchY:Int, touchBegin:Int Field whitebrush:TBrush Field init_gl:Bool = False Method OnCreate() SetUpdateRate 30 End Method Init() If init_gl Then Return init_gl = True SetRender(New OpenglES11) cam = CreateCamera() cam.CameraClsColor(0,0,80) light=CreateLight(1) 'sphere1 = CreateSphere() txt = TText.CreateText(cam) 'txt.NoSmooth() light.PositionEntity 0,3,-3 cam.PositionEntity 0.5,1,-5 'PositionEntity sphere1,-1,0,0 whitebrush = New TBrush whitebrush.BrushColor(200,200,200) 'sphere1.PaintEntity( whitebrush) 'sphere1.EntityCollision(1, COLLISION_METHOD_POLYGON, 1.0) 'sphere1.EntityFX(2) 'sphere1.RotateEntity(145,145,0) 'sphere1.ScaleEntity(2.0,2.0,2.0) cube=CreateCube() cube.ScaleEntity(0.5,0.5,0.5) cube.name = "cube" PositionEntity cube,-2,2,2 EntityType(cube,1) 'append the constant collision data to second sphere cube2=CreateCube() cube2.ScaleEntity(0.5,0.5,0.5) cube2.name = "cube2" PositionEntity cube2,2,2,2 EntityType(cube2,2) 'append the constant collision data to second sphere Collisions(1,2, 2, 2) 'update collisions using the ellipsoid to polygon and full sliding collision methods 'Collisions(2,1, 2, 2) 'update collisions using the ellipsoid to polygon and full sliding collision methods 'noise = LoadSound("sound.wav") old_ms=Millisecs() 'Wireframe(True) Print "main: intit done" End Method OnUpdate() If KeyDown(KEY_LEFT) cube.MoveEntity(-0.5,0,0) Endif If KeyDown(KEY_RIGHT) cube.MoveEntity(0.5,0,0) Endif If EntityCollided (cube,2) 'PlaySound (noise,0,0) cube.MoveEntity(4,0,0) Endif 'cam.PointEntity(cube) txt.SetMode2D() txt.SetText(fps+" fps ~nhow are you", 0,0) ' calculate fps If Millisecs()-old_ms >= 1000 old_ms=Millisecs() fps=renders renders=0 Endif UpdateWorld() End Method OnRender() Init() RenderWorld() renders=renders+1 End End ...............Thanks Again to everybody here lee |
| ||
Could you stick that in a codebox Lee, for readability? |
| ||
Hi, I wrote an rudimentary XNA wrapper and implemented an XNA target for miniB3D v0.2. Its not feature complete and not optimized, but the samples seems to work..so it might be an good starting point. There might be some places, where the opengl import was removed...in tlight for example I changed the import section of trender.monkey as follows: native/xna.xna.cs |
| ||
xna_render.monkey Suggestions are welcome. RONE |
| ||
AWESOME! Can't wait to try this out later this week. re:TLight-- updated github to remove that import (residual leftovers). re:TRender-- yeah, i wish there was a better way to seamlessly add in new targets, if anyone has a suggestion, i can add it in. great stuff! |
| ||
Updated xna.monkey: @trender: It seems, that I have to change the MINIB3D_DRIVER define in minib3d.monkey and call SetRender(...) in my application, in order to change the target. I suggest to manage the target specific imports ONLY with the TARGET define. The MINIB3D_DRIVER define can be removed then. Also the global stuff in trender needs to be encapculated in a seperate class...trenderManager, for example. New targets must only be added to trenderManager then. Changing the target can be done by only calling SetRender(...) personally I would also convert TRender to an interface and provide a factory... |
| ||
Cool XNA target! I will give that a go ASAP, as a general question is there a limit on verts for B3D mesh? I am trying to load a mesh and it draws then crashes with HEAP CORRUPTION DETECTED: after Normal block (#123638) Thanks. |
| ||
Whooooo!? XNA target!!! Does it work on Xbox 360? I am at home, I can't test now, but somebody please tell me! That is so damn awesome! |
| ||
Works also on Xbox360...but its really an early stage of development. Fixed a few bugs and added most features that are possible last night. There are also some Interface glitches that should fixed in miniB3D. Will upload the latest version this night.. Just have build glfw target for the first time, models are not displayed !?! Is there an common issue with that? I use v58 I also get an error in v59 with glfw: 'seh_call' does not exist 'StackTrace' does not exist |
| ||
Just have build glfw target for the first time, models are not displayed !?! Is there an common issue with that? I use v58 not that i'm aware of. did you test the examples? make sure the b3d file is base64 and in the ".data" folder. As for the v59 monkey error, seh_call and StackTrace() is same code from previous versions. (not sure why, i havent tried m59) |
| ||
@AdamRedwoods Yes, its the 'animation_test' example. 'TText' does also only work on Android.. ------------- Here is an update of the xna implementation. http://www.load.to/Qy9fTAYC9D/minib3d.zip Is fairly complete. A few things are missing, due to lack of support in xna reach profil ... Mesh manipulation and texture creation can be improved if the driver interface is extended... Todo: - SpriteBatch - CubeMapping |
| ||
@AdamRedwoods Have you ever thought about using interleaved vertex arrays? I do not know what that does with OpenGL on animated meshes, regarding the performance, but in general it would make many things easier... http://developer.apple.com/library/ios/#documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/TechniquesforWorkingwithVertexData/TechniquesforWorkingwithVertexData.html#//apple_ref/doc/uid/TP40008793-CH107-SW10 http://www.opengl.org/wiki/Vertex_Specification_Best_Practices |
| ||
Re: interleaving Would it make things easier for XNA/DirectX? I chose not to since I wanted to keep animation fast on android, although untested, my gut tells me the difference is minimal. I thought about just normal/texcoords/colors interleaving as well. Would require a system-wide change, so would require a few rounds of testing. |
| ||
Yes, exactly. Without interleaved arrays, it is very inefficient with xna / D3D. Also think that the difference is minimal at mehsh animations ... I'll try it ... Probably the most can be copied from miniB3DExtended. |
| ||
Ok, did it. Took 4 hours on a bug in this damn BoneToVertexAnim function to find.... Unfortunately, the original opengl implementation still does not work here...so I cant test if the opengl buffer binding is OK. |
| ||
OK, I can't seem to find a simple way to Interface TRender for simple compile picking with SetRender(render,flags). The problem is that Opengles11 and Opengles20 have consts and compiler defines that conflict with each other on Import. So I can't base this off TARGET or an Interface. This complicated matters, since I would like an easy way to switch between opengl and directx. My only thought is to degrade SetRender() to flags use only, and force the programmer to use: Import minib3d.driver 'driver = opengles20, opengles11, xna, dx11, etc... as the main way to pick the driver. What do you think? |
| ||
Sounds good, if understand correctly ....Something like this? Here's an update of the xna implementation(Shows also the above described driver handling) http://www.load.to/ddWbbVShsY/minib3d_3.zip Changed vertex data to 64byte aligned interleaved arrays(opengl will crash or not displaying anything, cause I have not yet converted openglES11.Render properly). Have found a lot of bugs after I included reflection: Most was easy to fix....some of it is just commented out, simply because either missed a class or I did not know 100% what the code does. |
| ||
Updated opengles11, in order to work with interleaved arrays. Tested with glfw and xna on pc and windows phone. http://www.load.to/EG8tjqGFMl/minib3d_4.zip Todo: - check matrices(might be twisted in xna) - add spritebatch to xna(copy/paste from opengles11 should work) |
| ||
Nice job. I'm going to change up the way the code is organized, not too major, but should help organize between multiple targets. Do I have your permission to add the XNA to the next GitHub minib3d version? |
| ||
yes, of course |
| ||
The following code works in GLFW, but doesn't rotate properly in XNA (both PC and Xbox360 have problems):#If TARGET="xna" Import minib3d.driver_xna #Else Import minib3d.driver_opengles11 #End Function Main() New Game End Class Game Extends App Field cam:TCamera Field light:TLight Field cube:TMesh Field init_gl:Bool = False Method OnCreate() Minib3dInit() #If TARGET="xna" Init() #End SetUpdateRate 60 End Method Init() If init_gl Then Return init_gl = True cam = CreateCamera() cam.CameraClsColor(0,0,80) cam.CameraRange(1,100000) cam.PositionEntity 0,0,0 light=CreateLight(1) light.PositionEntity 0,3,-3 Local x:Int For x = 1 To 10000 cube=CreateCube() cube.ScaleEntity(Rnd(0,10),Rnd(0,10),Rnd(0,10)) cube.name = "cube" PositionEntity cube,Rnd(-500,500),Rnd(-500,500),Rnd(-500,500) Next End Method OnUpdate() TurnEntity cam,0,1,0 UpdateWorld() End Method OnRender() Init() RenderWorld() RestoreMojo2D() DrawText "This is a test!", 0, 0 End End |
| ||
yes, as expected...frustum culling and lighting fail, too. matrices are twisted. |
| ||
Ok, matrices should work now...also TText and frustum culling. http://www.load.to/E88h9utXSY/minib3d_5.zip @Rex Rhino Do the samples run on xbox360? I was confused, because of that: Caution Here is a tip for rendering objects within the Draw method of an Xbox 360 game. Do not use SetData when writing data to vertex buffers, index buffers, and textures. This method may lead to graphics corruption or crashes. This is because, in cases where the size of the back buffer and depth-stencil buffer exceed the size of the Xbox 360 10 MB of embedded memory (EDRAM), predicated tiling is utilized on this platform to compensate for the additional memory requirements. Predicated tiling is a process by which scene rendering is performed multiple times on subsections of the final render target dimensions. When predicated tiling has been triggered, the drawing commands contained in the Draw function are not submitted until Present is called. (Note that Draw implicitly calls Present at the end of this method.) In this case, these resources are not available for modification until the GPU is finished with presenting the entire frame. |
| ||
Rone: I tested the zombie example on the Xbox 360, and got it working on the 360 (I didn't test the camera movement, because I didn't change the code to work with the controller). My example with the cubes was also running, although with the matrice problems on rotation. I haven't tested it with your 5th revision (I probably won't be able to until later tonight). As for the predicated tiling thing, it is usually only a problem when rendering 3D at 1080p. The standard procedure with Xbox 360 is to render at 720p, because the Xbox is able to automatically scale to all resolutions and it is able to render all in one go. Anyway, great work with what you are doing Rone! If there is anything I can do to help, just let me know! |
| ||
Rone: I tested the XNA on my PC with the cubes demo I made - All the cubes are now visible, but the lighting is only working on one half of the world, the other half of the cubes are dark grey. |
| ||
ok, thx. *fixed matrix rotation issue on pitch vector Since xna only supports 3 directional lights, each light is treated as a directional...I suspect the gray sides are only not illuminated(seems so, if you move around), but its possible, that the calculation of direction is wrong...in any case, it is ugly: local dir:= LIGHT_QUAD.MatrixToQuat(light.mat).RotateVector(UP_VECTOR) Update follows.. @AdamRedwoods In the conversion of the vertex format, I have added a class called VertexDataBuffer. It is simple, to copy the functionality to TSurface, but I would like to natively implement this class in c#, since the DataBuffer implementation is very suboptimal in c#(lack of unsafe code on windows phone)... |
| ||
Upadate *some speed improvements during rendering(no VBOs with dynamic meshes) *using float[] instead of DataBuffer for vertex manipulation is much faster http://www.load.to/c9suokb62P/minib3d_6.zip Since miniB3ds animations are done completely on the CPU, there is a good possibility to improve the performance, by just declaring TMatrix and TVector extern. This way we get SIMD acceleration for free on XNA/D3D based platforms(just need to enable SIMD flag)...also Android and iOS supports this, through NEON technology. http://justinangel.net/AllWp7MangoAPIs#simd http://www.arm.com/products/processors/technologies/neon.php |
| ||
I see, yeah, it is directional light... XNA only supports 3 directional lights with the "Basic Effect" (which is the XNA equivalent to the Fixed Pipeline in OpenGL). From what I understand, "Effects" are essentially shaders in XNA. Here is an effect that supports point lighting: http://www.catalinzima.com/tutorials/deferred-rendering-in-xna/point-lights/ Anyway, thanks for your work Rone! It is awesome! I am very excited this is coming along! |
| ||
Thanks. Unfortunately xna reach profile does not support custom shader on wp7(I was totally confused when I tried to load fx files). I also dont like the idea of recreating the FFP with a huge lame shader replicate... just as creating thousands of shaders for each lighting/material combination... But especially the way minib3d handles materials, makes a smart solution challenging |
| ||
How is lighting translated from Monkey to XNA? In XNA, it looks like it has a color, a direction, and a highlight color: http://rbwhitaker.wikidot.com/basic-effect-lighting How is that set and/or reconciled with the miniB3D style of lighting? |
| ||
Each light is treated as directional light. Color and orientation were simply transferred. Specular is still ignored ... OK, theres obviesly a bug... |
| ||
Cool! Looking forward to see what I can do with it! I am making a space strategy game - I was going to use abstract 2D graphics, but it will be a lot cooler with an abstract 3D system. Anyway, I don't know if I am up on XNA 3D to help you with the coding, but anything I can do to help otherwise, let me know. In my opinion, being able to do 3D on a bunch of different platforms (even if old school style 3D) make Monkey 1000X more valuable than it was before! |
| ||
Hi! When trying out a few things with this I get an error:C:/Apps/Coding/MonkeyPro59/modules/minib3d/tmodelobj.monkey<102> : Error : Duplicate identifier 'DebugLog' found in module 'lang' and module 'tutility'. Abnormal program termination. Exit code: -1 |
| ||
When trying out a few things with this I get an error: The latest monkey probably now has DebugLog, so minib3d is conflicting. I'll have to change this throughout. (EDIT: you may be able to just Rem out the tutility debuglog) One project I had lined up fell through so I may be able to catch up this week. |
| ||
I just commented out the DebugLog statements, and it worked fine. |
| ||
I'm a bit confused as how to load in 3D models! I see in the animation test example that there is a base64.txt of the b3d model. What do I have to do to load in b3d models? |
| ||
You need to convert your .b3d models to base64.txt files... |
| ||
How do I do that? |
| ||
https://www.google.com/search?btnG=1&pws=0&q=base64+encoder |
| ||
Ok, I've started to get XNA working with this new integration. Still a few problems left, and android is too slow (vertex animation) so I'll need to work on those issues, too. XNA integration has slowed me down a little. fyi Rone, since we've discussed this a little, i've set up the new format as follows (if you want to): +modules ++minib3d +++gl ----opengles11.monkey ----opengles20.monkey ----tpixmapgl.monkey (and others, etc) +++xna ----xna_render.monkey ----xna_pixmap.monkey (and others, etc) ++++xna_driver -----xna.monkey +++++native ------xna.xna.cs so now to choose a driver, people are forced to do: [monkeycode] Import minib3d.gl.opengles11 '' ...or... Import minib3d.gl.opengles20 '' ...or... Import minib3d.xna ''then SetDriver(flags) ''or whatever call to init() [/monkeycode] this keeps hardware implementations tidy in their own folder and removes #MINIB3D_DRIVER. ...more to come later, as minib3d+monkey v0.30 will be a massive change, but will offer new targets and shaders. |
| ||
Lovely! :) |
| ||
Hi, is there a limit on verts with b3d files? I have converted a couple of simple models and they load, draw once and then it crashes... |
| ||
Hi, is there a limit on verts with b3d files? I removed that limit, but there is a trimverts function which caps at 1,000,000 verts. Is this opengl or xna? |
| ||
Keep it up. Looks great. |
| ||
Obligatory 100 zombies screenshot. Opengl lighting is backward. XNA lighting does not allow attenuation, or point lights. But if XNA is going to DirectX, then that should help, but will mean a rewrite for this target.![]() |
| ||
Hey, looks good... also the import stuff is very clean now! Looking forward to your gles20 implementation...I have implemented the external xna interface for pss target. Your shaders should work there, without magnificent changes... But if XNA is going to DirectX, then that should help, but will mean a rewrite for this target. Hopefully, they just unlock custom effects on windows phone. Anyway I will implement a shader driven xna driver. Then the missing features must only be considered if Windows Phone is targeted. |
| ||
Hi Adam, it's OpenGL and the model has less than 10,000 verts, I am saving to a b3d from UU3D and then converting to base64, it does load and draw it but then just crashes, If I create a simple shape in UU3D and do the same it works... Thanks. |
| ||
@CopperCircle Did you try to run the native project(.build\glfw\vc2010\MonkeyGame.sln)? You need to enable C++ Exceptions at Debug->Exceptions... Visual Studio shows the method/line where the error occurs, if monkey does not. |
| ||
it does load and draw it but then just crashes i'll either need a crash error or you can send me the model at my spam account (remove the nospam): awNOSPAMpiette at NOSPAMyahoo dotcom. |
| ||
Thanks, I email the model over and Rone I'll try running it in Visual Studio to find the error location. |
| ||
Here's an update of my xna implementation.. *fixed a few bugs *implemented basic pss target(showing a black screen...but compiles at least :) ) @Adam The upload contains also an incompatible b3d model(ind1_hall1.b3d). Crashes at TrimVerts ... if I remember correctly. http://www.load.to/Ebdsd8T1Sx/minib3d_40.rar Edit: added 'f = f.Replace(".tga",".png")' to LoadPixmap, because of the model tries to load .tga files) |
| ||
Hi Adam, did you get my email with the b3d model? |
| ||
Hi Adam, did you get my email with the b3d model? I did, sorry to be slow. I tried it out and it worked in v0.20 that I posted on github. I did get an error in tbrush, but deleted the line and it worked. Are you using the latest v0.20? I may have updated it in a few places (i'm very bad at versioning), try updating TSurface.monkey and TModelB3D.monkey. |
| ||
I have made sure i'm on the latest but my ship model still makes it crash as soon as it runs. HEAP CORRUPTION DETECTED:after Normal block (#108605) at 0x08A246C8. CRT detected that the application wrote to memory after the end of heap buffer. In VS2010 (with c++ exceptions enabled) It just says: The program '[1404] MonkeyGame.exe: Native' has exited with code 3 (0x3). Thanks. |
| ||
You must also enable 'Win32 Exceptions'(best is enable all)... Visual Studio will break at the line where the error occurs. Go through the call stack, in order to find the accordant miniB3D method... '---------------------------------------------------------------- xna update: * fixed a lot of issues with the external xna interface * added missing methods to XNAEffect & XNAEffectParameter * added HLSL driver for xbox360 and windows( shader is not complete yet..just an ugly test shader) * implemented Matrix & Vector extern.( Might be slow on android currently, but this way the different APIs will collaborate much better with miniB3d) http://www.load.to/GMcByhPCIz/minib3d_v60.zip Since .fx files needs a different content- importer and processor, its necessary to change the xna target as follows: src\trans\target.monkey src\trans\targets\xna.monkey targets\xna\CONFIG Then build and run \src\rebuildall.bmx. |
| ||
Thanks Rone, turns out it was my models, I was using UU3D to texture and save as .B3D, I loaded them into the trail of fragMotion and saved them again and they now work. I'm planning to port a level from my 3D XNA game to Monkey minib3d and then compile to all platforms (including XNA again) and compare results/speed... |
| ||
Adam, I found a bug in opengles11.monkey: In UpdateLight, glLoadMatrixf(light.mat.ToArray() ) needs to be replaced with glMultMatrixf(light.mat.ToArray() ). I wonder how that worked ever since your screenshots look correct, but I get only right results with glMultMatrix..? I'm also confused about the attenuation factors you use...cause I'm not able to reproduce the same lighting using the same factors with hlsl While trying to connect the attenuation factors with the light range, I found this explanation: http://imdoingitwrong.wordpress.com/2011/01/31/light-attenuation/ att = 1 / ((d/r)+1)^2 ==> att = 1 / (1+(2/r)*d + (1/r^2)*d^2) Using this factors, I get much better results and can repoduce the ogl lighting, more or less. What do you think about it? |
| ||
Just a quick note, ExtractAnimSeq does not work until you increase the first/last array size in tentity.monkey Field anim_seqs_first:Int[1] Field anim_seqs_last:Int[1] |
| ||
Ok, thanks for finding these bugs! For ExtractAnimSeq and LoadAnimSeq in TEntity.monkey, the array needs a Resize(). I've updated this for the next version. For light attenuation, it took a while to match miniB3D. The light distance equation for my pixel shader is: d = (lightAtt[0].w* spotlight) / ( lightAtt[0].x + (lightAtt[0].y* dist) + (lightAtt[0].z*(dist * dist)) ) ; if (lightType[0] ==1.0) d=1.0; lambertTerm = clamp(NdotL * d , 0.0, 1.0) ; where lightAtt[].xyzw is light[0].const_att, light[0].lin_att, light[0].quad_att, light[0].actual_range Note I added an actual range value. minib3d originally stored the 1.0/range (which i kept intact, thus needing an actual_range variable). |
| ||
whats spotlight? if lightType[0] = 2 then spotlight = 1 ??? Do you use no attenuation at all, if lightType[0] == pointlight ??? |
| ||
Spotlight =1 for point lights Spotlight = the spotlight equation which includes cone falloff, etc. |
| ||
Small bug, One Shot Animation would only work once until I changed trender to this:ElseIf mesh.anim_mode = 3 ''one-shot, hold at end mesh.anim_time=mesh.anim_time+(mesh.anim_speed*anim_speed) If mesh.anim_time>last 'mesh.anim_time=last mesh.anim_time = first + (mesh.anim_time - last) mesh.anim_mode = 0 Endif Endif |
| ||
Bug in opengles11.monkey. When rendering multiple objects with different count of textures, the texture layers are not deactivated properly. Added the following fix to OpenglES11.Render: if tex_count < last_tex_count For Local i = tex_count until 8 glActiveTexture(GL_TEXTURE0+i) glClientActiveTexture(GL_TEXTURE0+i) ' reset texture matrix glMatrixMode(GL_TEXTURE) glLoadIdentity() glDisable(GL_TEXTURE_2D) Next EndIf last_tex_count = tex_count For Local ix=0 To tex_count-1 ... |
| ||
Adam, How are things going with the GLSL version? I'm really interested in how you've solved the things. I got a nearly feature complete hlsl version running...and although I have not much experience with shaders and its not optimized... it runs pretty fast - up to twice as fast as the gles11 with 4 lights, a 512x512 terrain and 1000 trees. But only shader version 3 for now. will upload tomorrow, need to clean up a little first :) |
| ||
Wow! That is super exciting! I don't know anything about HLSL, but I cobbled together a nice GSGL shader that was basically the old OpenGL fixed pipeline stuff, except with the addition of normal mapping and illumination mapping, figuring that would be highly usable for just about any vaugly realistic game. It would be cool to have a generic shader built in that is highly useful for those who don't need to make highly customized shader. |
| ||
funny you should ask, i'm tidying up and getting ready to upload v0.30. great to hear xna is coming along! very exciting. for my v0.30 I've added in an earlier version of your xna and changed a few things, but we'll have to circle back after both versions are out and see how we can integrate them better. |
| ||
Edit: wrong thread |