bOGL 2 - OpenGL 3D engine in BlitzPlus
Community Forums/Showcase/bOGL 2 - OpenGL 3D engine in BlitzPlus
| ||
| Finally put enough in v2 to call it complete, so as promised, a new thread for what is effectively a new engine... May I present bOGL 2: an OpenGL-based 3D engine written entirely in BlitzPlus! (what do you mean, "why?") You can find the thread for bOGL 1 by Andres (and the origins of this version) here. Features: -- Hierarchical B3D-style entity system -- B3D-style command set -- Loading and saving static meshes (OBJ format) -- Loading and playing animated meshes (MD2 and BO3D* formats) -- Hardware-accelerated 2D drawing system -- 3D collision detection -- Particle system -- Event-based entity control (like cocos3D Actions) -- FX, quaternions, stencil buffer, blending, etc. -- decls files for syntax highlighting -- named constants (for FX flags and so on) -- fully open-source, original code -- full hand-written documentation (with clickable links! click them!) -- 100% pure BlitzPlus: no DLLs GitHub project page (download from there) Note that unlike miniB3D, bOGL is not (and is not intended to be) a Blitz3D clone. It's only "inspired" by B3D enough to look familiar to Blitz veterans. Many of the commands are intentionally different, the coordinate system is native to OpenGL, and many features work completely differently. There is no B3D or miniB3D code in this project.  Installation is very simple: copy the contents of userlibs/ to your BlitzPlus/userlibs/ folder (make sure to overwrite any old OpenGL .decls - these ones are updated and different). Then run from wherever you like, because apart from system declarations the project is 100% Include-based. Take a look at the bundled "...Demo.bb" files for program structure. *BO3D is a custom mesh format inspired by but not the same as the B3D format. You can convert meshes from B3D to BO3D using a conversion utility in Tools/ - this needs to be run with the real Blitz3D atm. It may not be the most useful project in the world (an OpenGL 1.1 project with absolutely no scene optimizations... yeah), but building this was great fun anyway. I encourage everyone who hasn't to try doing something similar. I don't really care that it's useless, I'm pleased with it. Oh and again... clickable documentation! (I am perhaps unreasonably proud of that) |
| ||
| Very cool ! I was looking through the code on github earlier. When will you finish the BlitzPlus OS X port? :-) |
| ||
| I haven't forgotten about it... I'm not sure whether to port or to reimplement though. I was thinking of replacing the Blitz2D engine with SDL + a command set emulation layer (since Blitz2D does most of the same things but isn't supported any more) - but since that means throwing away like 80% of the entire project, I was toying with simply abandoning the whole thing and working from scratch. |
| ||
| Thank you Yasha! |
| ||
| Always knew yasha is one of the good guys :p |
| ||
| SWEET! THANKS YASHA! :D Now we have Blitzplus + BOGL - Hardwired + (Win32) (I added Win32) :) Blitzplus is the new successor to Blitz3D! :D KUDOS TO YOU, YASHA! KUDOS TO YOU! :D ~GF |
| ||
| Wow, I wasn't even aware of bOGL 1 !! This follow up looks really good. I love the way that blitz in general is getting a great deal of options this year - it's a great turn around which blitz thouroughly deserves. Right on, Yasha. Long live blitz!! |
| ||
| ^ And long live hard wired! :D |
| ||
| Hi Yasha, I'd just like to say I'm nothing to do with the above, and would prefer that GF takes out this last post. I know what that's like to work on this kind of project, so I can totally respect that this thread is about bOGL2 and that you must have put a lot of work in it. Your project merits the attention it deserves. Although the two engines are not in any kind of competition (they kind of go well each other actually), I feel that this is not the right place to focus on anything other that bOGL2. Although I appreciate the gesture from GF, I really do, I kind of undrstand that already. But here it just seems inappropriate. All the best, and thanks for sharing this great addition for blitzplus. |
| ||
| Looks interesting... I noticed that there is no Z-sorting of entities, so alpha entities could have problems when you move the camera to the other side (but it should happen only if there are two or more alpha meshes). Also, all entities are rendered, even if they are outside of the camera view: this makes updating easier (in minib3d/openb3d, every command that affects an entity must act recursively on all its children; in bogl that's not needed, since a simple glPushMatrix does the trick), but the rendering might be slower, because you have to render entities that does not need to be rendered (and you can't avoid to do that, because they might have children that need to be rendered, even if the parent doesn't) The way you used stencils is similar to what I used in openb3d... we worked in a different way, but we come to a similar solution. I liked your idea of event-based control... looks really simple and intuitive. Maybe I should add something similar to openb3d? |
| ||
| Yeah Z-sorting and culling both fall into the category of "advanced features" that I couldn't really be bothered with; partly because of performance/complexity concerns (culling is "just" an optimization but would take up quite a lot of space in what is supposed to be a file you can read in one sitting), and partly because the end user should consider either a more powerful "real" engine, or manual scene management with ShowEntity &c. (Looks like I forgot the EntityAlpha 0 optimization... I'll add that next time I'm near the machine.) bOGL actually does maintain independent global transform information for each entity - it doesn't stack glPushMatrix calls (I'm not sure that even works for an arbitrarily-large hierarchy - isn't it limited to about eight or something?). I think the main difference from miniB3D is that it waits to update child entities' global transform until something actually wants that information, so that if you put e.g. three separate movement calls to the same entity in quick succession, you don't end up actually traversing the child tree three times. (Having a "isGlobalPositionValid" flag and updating only when queried-and-false has been heavily criticized as "typical C++ bull****" in other engines though, so this may have been a bad idea.) The event-based control is indeed an awesome idea. I don't deserve any credit for it though! You should take a look at cocos3D and their CCAction class, which is the original, and copy them! |
| ||
| Nice one. |
| ||
| With this version of BlitzPlus using OpenGL, does this mean it is now a possibility that this project can be ported to Linux/OSX? or do you have plans to port it? Awesome job, thanks for sharing!! |
| ||
| ..oh..i never heard of this before..this is very nice.. |
| ||
| Thanks guys. Since bOGL is all BP code + OpenGL, it doesn't depend on Windows. The bigger obstacle there is BlitzPlus itself! I've ported bOGL to SDL+C because I actually like using it, simple as it is (and later will update the backend to modern OpenGL). I'll polish that and release it soon; that will run anywhere SDL does. I ...have been talking about porting/rewriting BlitzPlus for OSX and Linux for some time, but I work in geological timescales (and am so easily distracted by the thought of extra features...). Will do it sooner or later. Start a petition in General Discussion if you like. |
| ||
| Ok thanks and this will be good news! As always, great stuff Yasha!!! :D |
| ||
| This is really a cool project. However I can't get fullscreen to work. is it available? thanks for sharing Yasha. |
| ||
| I can't get fullscreen to work. is it available? Creating a window is left up to BlitzPlus, so Graphics3D just passes its mode parameter straight through to the underlying Graphics command (parameters are therefore same as native)... can you use fullscreen 2D graphics with other programs? Are you using a window size that your system supports in fullscreen? This is unlikely to be a bOGL issue, as it creates the graphics window before ever attempting to do anything with OpenGL. |
| ||
| Thanks Yasha. So when I do this: Graphics3D "bOGL", 1024, 768, 32, 2 It works ok. But when I set it to Graphics3D "bOGL", 1024, 768, 32, 0 to get it to fullscreen, I get blank. can you use fullscreen 2D graphics with other programs? Are you using a window size that your system supports in fullscreen? Yes fullscreen 2D works perfectly in all my resolution listed in BlitzPlus Graphics command All your examples are set to windowed mode or am I missing something? |
| ||
| OK as far as I can tell this issue only appears when using Blitz3D as the compiler rather than BlitzPlus. I don't fully understand what Blitz3D does, not knowing DirectX, but it looks like whereas BlitzPlus actually creates a fullscreen window we can then grab, Blitz3D doesn't use the window proper (instead hiding it with zero size) and instead uses... some DirectX thing? So the context needed for OpenGL to draw on doesn't appear to be available. It's trying to draw the graphics to a minimized, hidden window. Not sure this can be fixed easily (i.e. without getting rid of the reliance on Blitz's builtin Graphics command - which would add a lot of weight to reimplement). Might have to remove the label claiming that this works with Blitz3D as well as BlitzPlus. |
| ||
| OK as far as I can tell this issue only appears when using Blitz3D as the compiler rather than BlitzPlus I don't understand this one Yasha, I'm using the BlitzPlus compiler not Blitz3D (already uninstalled) and this is got me interested in your project in the first place.. bOGL: 3D in BlitzPlus I don't understand the Blitz3D relevance but care to explain? Thanks. |
| ||
| Ah right. Since BlitzPlus and Blitz3D are linguistically the same, and this only relies on built in commands from the common subset (except for the easily-commented CreateCanvas3D), the code should supposedly run under the B3D compiler as well. Not that there's any reason to do so, just that it could. Anyway by what turns out to be coincidence, doing that wouldn't work in fullscreen for entirely unrelated reasons. All I can say is that I was unable to reproduce this problem myself. With BlitzPlus, it works perfectly in fullscreen for me. (Interesting aside: bOGL is basically completely unusable under Wine. This is weird because you'd think OpenGL would work perfectly, and normal BlitzPlus programs themselves are apparently platinum-rated... could be related. Wish I knew what I was doing here.) |
| ||
| Are you still working on it? |
| ||
| yeah, I was about to ask the same thing. GLSL Shader support? |
| ||
| Hey guys, sorry I don't check this subforum very often. I am unable to reproduce the error described by videz on my own limited access to Windows machines at the moment. Aside from that, bOGL seems pretty feature-complete to me; I can't think of any more libraries to add (anything more complicated belongs to a "game" engine rather than a "graphics" engine). At some point I intend to release a demo game. Still willing to take suggestions, or keep looking for that error if someone can help narrow down where it might be (but I've tried on three machines and not seen it on any of them). I'm not inclined to put GLSL support into this version of bOGL for two reasons: 1) it would require a complete rewrite to use a newer OpenGL version; 2) the reason I didn't use a newer version to begin with is that anything more requires callbacks, which means support DLLs, which means no pure BlitzPlus. |
| ||
| I implemented in OpenB3D something similar to your 3d actions (no strings are used, and commands like ScaleBy are not implemented, and rate parameter set a constant speed, otherwise it's identical); it will be available in the next version. About GLSL, actually it does not need callbacks/DLL, but it overcomplicates things: you need a vertex shader and a fragment shader (it means two external files) for every effect (one for vertex color, one for flat shading, another for smooth shading, others for every way to blend textures, other for multitexture, another for spheremapping and for cubemapping.... plus all the possible combinations of them. And all that just to get back the same features you already have with fixed pipeline, gaining no advantage at all! And, if you write a default shader (like in monkey minib3d), it means that every alternative will ha e to work in the same way, so replacing it with a custom one will be almost impossible. About suggestions: in the past, you talked about a physics engine, didn't you? I am adding some physics feature in OpenB3D, and I would have liked to see if you were going to implement something in a similar way, to see if you would come up with a solution similar to mine or with something that is completely different. |
| ||
| you need a vertex shader and a fragment shader (it means two external files) for every effect (one for vertex color, one for flat shading, another for smooth shading, others for every way to blend textures, other for multitexture, another for spheremapping and for cubemapping.... plus all the possible combinations of them. Not exactly. You can put the vertex and fragment shaders in one file. http://www.gamedev.net/topic/651404-shaders-glsl-in-one-file-is-it-practical/ Though I have to agree with you on not needing DLLs to have it.. I'm not inclined to put GLSL support into this version of bOGL for two reasons: 1) it would require a complete rewrite to use a newer OpenGL version; 2) the reason I didn't use a newer version to begin with is that anything more requires callbacks, which means support DLLs, which means no pure BlitzPlus. Yasha, it's a shame having invested your time into something which feels like incomplete or half done. You're diving into OpenGL, why not create the whole shebang? I hope I'm not insulting in any way rather I'm just stating my opinion. Don't hate me for this and keep it up! |
| ||
| I've got a simple collision system at the moment that has a simplified version of B3D's functionality (stop-colliders); decided that was more appropriate for the scale of the project. I was thinking more about a 2D physics engine - a 3D physics engine is a big beast, best left to the experts at Bullet and so on. Re. callbacks - OpenGL functions are loaded at runtime unless the OS provides a static ABI. On Windows (the home, for now, of BlitzPlus), that ABI is limited to OpenGL 1.1. Language limitations of BlitzPlus make working with function pointers near-impossible, which in turn means the dynamic function loading required to use OpenGL versions beyond 1.1 is rather difficult, in a way that you wouldn't experience in BlitzMax or C++ (where language-level support for function pointers makes this completely transparent to the user). This isn't specific to GLSL, it applies to the entire OpenGL API above version 1.1. I can think of workarounds, but I can't think of one that would be suitably fast without needing to use at least a very thin wrapper DLL. (What I have done is publicly committed to developing an updated Blitz Basic with support for, among other things, function pointers. That will solve this problem in a different way, without compromising the original goal of language purity.) |
| ||
| Hi Yasha, any plans to update this cool library? A few questions actually.. 1) Does the RayPick works the same as Linepick? 2) Any major equivalent B3D functionalities that are still not implemented? 3) Also curious about 3dsound (aka CreateListener) 4) Can I use some minib3d/openb3d functions to make up for missing functions. ie. AlignToVector, etc. I like the new event based movement approach. it really looks promising. thanks |
   |