Jeff Quan's Xojo software

GL Classes

CORRECTION: This once was a replacement of RB3D, but has now turned into a modern implementation of OpenGL with a minimum support of OpenGL 3.3. I've gutted much of the original RB3D to make this happen with nearly a ground-up rewrite -- it's long overdue.

• Compiles under Xojo for Mac and Windows
• Import files using the Open Asset Import Library
• Basic shapes: Box, torus, disk, sphere, cylinder. There's even an extrude shape and rudimentary path extrude shape as well. These are all created in code and no longer require the GLU library.
• Extensive support for OpenGL extensions

Preview of what's coming for GL

March 7, 2018

Movie: Robotron game in-progress.

Apologies for the long silence, but Xojo3D is very much alive and kicking. I'm happy about where it's at and am going to release it soon. I've been debugging by writing a game: See Robotron movie at right. In the meantime, here is a link to a rough class hierarchy and math functions in PDF form for you to peruse: class hierarchy. I am currently finishing a quick start guide, but a full manual is still far off.

June 27, 2017

Because of another user, I've decided to focus on 64-bit support. I can now say that it is supported by my base classes, but where I'm running into trouble is in the Asset Importer (ASSIMP for short) libraries. Xojo has spoiled me: compilation is so dirt simple that I cannot fathom the intricacies of CMake and how it generates code for compilation. While I've documented the steps that I took to compile ASSIMP successfully, there is no guarantee of repeatability for all permutations of 32/64 bit support.

If you are reading this and are a guru on either Xcode or minGW, I'd love some help as I really want to provide libraries for all cases!

An aside: I was able to patch the older version of my classes to work with 64-bit compilation. It's not something I'm actively maintaining, but fortunately there weren't many changes I had to make.

On the Mac side, Xcode is pushing further and further away from 32-bit support, so while I can compile the latest ASSIMP library as universal, it only seems to work under 64-bit. I did not keep the older Xcode compiler and even when I add the older Mac SDKs (i.e.: 10.7 tp 10.11), the 32-bit portions don't seem to be working even though the compiler doesn't complain one bit. Bear in mind that I am a complete neophyte when it comes to Xcode, so perhaps there is some step I'm missing, or perhaps it isn't worth pursuing at all as 32-bit falls by the wayside.

On the PC side, while I have the 32-bit library working I have NO idea how to compile a 64-bit one. I've been using MinGW and know NOTHING about how to use it (seriously: all I know how to do is to enter the directory with the make file and type "mingw32-make"). I've tried using other people's precompile 64-bit dlls, but they fail to load a model, the ASSIMP error log telling me that something failed to parse properly. I'm still in the process of throwing different 3D formats at it to see if it fails in all cases, but ideally I'd love to do a compile directly on my machine.

May 9, 2017

Movie: jet with Shadertoy backdrop.

I have fixed a few more bugs, most notably one in handling textures with an alpha channel. My biggest mistake was not reading the documentation for Picture carefully enough.

I've been starting to really work on making a real app using the API, which is great for bug hunting. I've been pulling snippets of things from here and there to see if everything is working properly, especially on the GLSL end. I've figured out how to translate Shadertoy.com shaders, which is a big deal to me because I really respect what those geniuses share.

The last step is the hardest: writing a manual. While I've done PDF in the past, Wiki might be better as the API can change. What I really want to do is something like LearnOpenGL.com and write it like a series of tutorials, but that is quite a commitment!

July 4, 2016

For the past month, I've been working on hooking up the model loading functions from the old RBGL into this. After sweating it out with the .OBJ loader and looking at the .3DS loader I wondered if I could do something different. Turns out there is: hook up someone else's importer.

So now I'm working in the Open Asset Import Library (better known by it's cheeky contraction "assimp"). It took a while to write owing to the fact that I had not only stick to the C API and parse much of the structure by hand, but I also had to compile both dylib AND dll on my own (and I really know near ZILCH about using Xcode and minGW, so I hope I compiled them correctly)!

Even though some of the test files provided by Assimp may crash the app, I'm still able to load far more file formats than before. I'll also note that both dylib and dll were compiled with the latest: Assimp 3.2 as of this writing.

Now I still need to figure out how to structure the data upon loading for the "just load it and show me something onscreen" crowd. There is a gold mine of data that is imported, including animation data, cameras, and lights. My focus is on the bare minimum of displaying a static mesh, but for power users I've parsed everything (with a few errors: recall that I mentioned certain files crashing things).

While I may have parsed the entire structure, I have not implemented every function. Assimp has the ability to export which I haven't written in yet, but both dylib and dll have that capability in them: I did not compile them out even though that was an option.

April 27, 2016

I've been chugging along with the rewrite and have some of the basics working.

• I have methods in place to create a mesh from scratch or load a .OBJ file.
• All of the vector/quaternion/matrix math has been moved into its own Module, leaving glVector3D, glVector4D, and glQuaternion as simple data holders.
• There is better GLSL program handling
• Aside from the original gluQuadric shapes, there are now lathe, extrude, and path extrude shapes.

Big change #1: mesh vertex data is now written to the GPU in an interleaved format. This is supposed to be the preferred way of doing things and it is certainly how iOS prefers it (settle down: these classes only work on OS X and Windows).

Big change #2: mesh vertex data no longer has explicit glVectorLists, glUVlists, or glColorLists. Because it is now up to shaders to determine how to use the data, making things explicit no longer makes sense. The vertex data is now more generic and because of this allows one to define more than just positions, normals, UVs, and colors for vertices.

Big change #3: The killer in all of this is the glSpace: There is now no single way to render a mesh: it is now up to how your GLSL shaders will use them. The Render Method is just an empty shell waiting to be filled. While I'm still trying to figure out a way to make things easy, the bottom line is that you really need to know how to use GLSL shaders to be effective. Without going into specifics, a simple render loop would be:
1. Activate shader for use.
2. Set any parameters needed by the shader.
3. Render the meshes affected by the shader.
4. Repeat steps 1-3 for every shader.
This sounds straightforward, but it's not. Right now it is up to the user to fill in the Render Method with whatever code they need.

That said, I'm planning to make a default render module to make things easy. Here's a look at the default, which accommodates multiple textures, normal maps, spot lights, and a single shadow source (click to enlarge):

jpeg image

mp4 movie

February 19, 2016

So I've finally taken the plunge this year and figured out how to get OpenGL 3.3 and higher working on both Mac and Windows, with the latter being particularly pesky but large roadblock (at least for me it was).

This is great news, right?

Not quite.

Creating an OpenGL 3.3 context forces GLSL to come to the forefront. While the current classes allow for GLSL, it doesn't have the proper hooks for the more modern flavor of the shader language. Plus much of the commands under old OpenGL are now deprecated.

I do take this as an opportunity to do a rewrite of the classes to take advantage of the new and to clean out the old: As happens with such a large project the tentacles start to weave everywhere and thus the codebase is more fragile than I'd like. Plus I'm brushing up on my GLSL as I need to include at least one or perhaps a few of them as defaults -- I'd rather have you the user hit the ground running than to run into a brick wall right off the bat.

Unfortunately this will mean a substantial rewrite to any existing projects as the API will change drastically to suit the new OpenGL workflow. While this sounds awful, I'll leave you with this: I was able to render 350,000 individual cubes while maintaining 60 FPS in the Xojo IDE, something I could not even come remotely close to hitting under my older classes. I will preface this in that that nothing was moving, so take the result with a grain of salt.

What does this mean for the old classes? As I do not have the time to maintain both this may very well mean the end-of-life for that. Still, getting to OpenGL 3.3 is exciting to me and cleaning house has been long overdue!

September 25, 2015

More bug fixing and new enhancements. I can happily report that Windows 10 works just fine with the classes, and I believe I have removed a long-standing error message that was caused due to me not paying enough attention to OpenGL protocols. At this point, the only thing I can find missing under Windows is antialias support.

Much focus has been done for overlays: these overlays are basically masked textures that can be plopped atop a glSpace or a glCamera like a picture frame. You can stack as many as you'd like, and you may even move/rotate/scale them. You can even have multiple textures on an overlay (although your OpenGL implementation will cap that amount). I think I'm about to make it to being a glElement subclass and provide a few more glStates to take advantage of them.

February 12, 2015

Things have been moving along to the point where I have been focusing on optimization. The most surprising one has been finding out that the built-in OpenGL commands in Xojo are SLOWER than implementing them as soft declares on both OS X and Windows! It's an order of magnitude slower, so until this changes I will be using soft declares for making calls into OpenGL. So far I have been pleased with the resulting boost, allowing me to have hundreds of objects in motion running at 60 FPS on a 7 year old Mac. My virtual PC also shows similar speeds.

I've been also trying out in-lining functions, trading function call overhead for duplication of code. There have been some surprises here: it doesn't always go faster despite it being the same code as an external function. I haven't figured out why it sometimes works and other times doesn't at this point in time.

Lastly, I have been playing around with rewriting the reference manual. At nearly 200 pages it's now a bear of a document, one that could use better organization and more succinct writing. To that end, I've been toying with the design to see what will work best.

January 3, 2015

It turns out it is very possible to have multiple glSpace controls on a single Window. It's about as inefficient as RB3D in that one cannot share models across two glSpaces, but as long as one can live with that limitation, it is usable. The sharing issue is something that I'm not sure that I can work around. Sharing has to be done on control creation, and OpenGLsurface does not seem to give enough of a hook for me to share data (it would need to be within OpenGLsurface.Configure). Also, another interesting quirk is that simply calling glSpace.Render to update is not enough and will only update the topmost glSpace. It turns out that the solution is to call glSpace.Refresh for every glSpace and everything renders fine.

There is a caveat to all of this: keeping track of which glSpace is active is up to you the user. This is where OpenGLsurface.MakeCurrent comes into play, as it will need to be used before any OpenGL commands are called to set which glSpace will receive the upcoming commands.

December 30, 2014

Testing/bug fixing continues and I haven't broken the Windows build yet, so that's good. If you want to test Windows, email me and I'll send you the latest.

I have been able to add in something that I've been working on for a while: having multiple camera views to a single glSpace. While this isn't the same as running more than one glSpace control (still working on that one), it is significant for implementing shadows, which has never quite worked right. Still, my goal is to be able to have multiple glSpace controls but I'll most likely leave the multiple camera views code in place. There is also a class called glOverlay2D that overlays a texture over the entire glSpace window so that one can frame the glSpace with a pretty picture and thus further hide the glSpace's rectangular shape (which is great for drawing borders around multiple camera views).

December 12, 2014

I am cautiously optimistic: I have finally have Windows 7 Pro x64 working for the first time ever! This just happened today, so there is plenty of testing still to be done. Even though I am using a virtual PC, I have hope that it will run on a real Windows machine. There are issues that I would like to resolve, like why some of my Framebuffers don't seem to work (fortunately I was able to work around it, but it bugs me still) and why I need to call OpenGLSurface.MakeCurrent at all to keep OpenGL active. There was also the issue of cleaning up lots of duplicate properties (654 of them, ugh) as Xojo 2014r3 is more strict about these things.

Still, I'm able to run it in the IDE on 2014r3 for both OS X and Windows. I need to try compiling and I'll have others help me on the Windows side when I'm ready as I don't have a Windows Xojo license, though I can compile on my OS X for Windows.

Cross your fingers!

February 28, 2014

So I finally have a Win 7 virtual PC to test on and I can say that the seas have been rough: While RS1011r2 compiled correctly for OS X and Win XP, the latest version of Xojo doesn't work well for Windows at all. Something has changed and I haven't figured out what. I've been coding with Xojo directly in Win 7 to see if I can solve the problem there, but I'm running into corruption issues with VAO/VBO calls. In contrast, Xojo on OS X has been just fine.

December 20, 2013

Versions, versions, versions. While I have OS X and Win XP running lock step with each other, problems abound when using Win 7/8. I am starting to suspect that I need to request an OpenGL Profile of 2.1 in order for it to be compatible. While this in and of itself doesn't look complicated, rewriting the code to also account for OpenGL 3.2+ is as many things have changed under the hood. It turns out that if you want the code to be compatible with 3.2+ and use all of the new stuff (GLSL v1.5+ is a good reason), much of the GLSL shader code has to be rewritten.

There's also the matter of using RB2011 vs. Xojo — what works in RB2011 (where the codebase is written) might not work in Xojo. So while I can compile on a Mac for OS X using either RB2011 or Xojo in both Carbon and Cocoa, for Windows I can only successfully compile from Mac RB2011. If that sounds confusing, it is.

October 21, 2013

I'm pleased: I cached Windows PFNs and now Windows is running faster than ever!

October 17, 2013

I've made some progress on the Windows side and at this point I believe I have got it running feature parity with OS X. Much of the work has been making sure there are no OpenGL calls that are missing an appropriate delegate, as well as making doubly sure that I have all framebuffers pointed to where they need to be. Right now I'm very happy to see the GLSL functions working under both platforms, and especially glad to see that the GLSL-based glow and radial blur effects working correctly under Windows.

There is still more optimization work to be done on Windows, however, and much of it lies in the domain of caching Windows PFNs (Page Frame Numbers) so that they're not being retrieved over and over as they are now.

October 9, 2013

Based on another user's needs, I've added 2D overlays and multiple cameras within a glSpace. I'm still working out the details as to how they'll be accessed, but here's an overview: for 2D overlays it is treated as a full-screen quad with multiple materials applied to it. The overlay is stretchy: it will always cover the entire glSpace (masks are allowed to cut out holes in the material). For cameras, there is an array of glCameras, so there is technically no limit on how many cameras can be active at once. However, each camera renders the scene from its viewpoint, so it will eat into frame rates considerably (ie: two cameras will render the scene twice, three cameras three times, etc.). Each camera will also draw into the same glSpace that they're attached to in however the user wants. Most importantly is that overlays and cameras are working cross-platform.

There are also fixes for Windows users, mostly behind-the-scenes OpenGL calls that were not working properly. There are TONS of OpenGL calls that need fixing for Windows, and there will be an overhaul in the future to store function pointers permanently so that they're not called anew each time a function is called. If that didn't make sense to you, go look at any Windows-based OpenGL example and you'll see lots of lines defining things like:
    glMultiTexCoord1fARB = (PFNGLMULTITEXCOORD1FARBPROC) wglGetProcAddress("glMultiTexCoord1fARB");
It is these types of lines that causes me to add a delegate for any call currently being used by the classes, and the problem is that Windows will not support anything beyond OpenGL v1.0, which makes for a lot of bloat in the code.

September 17, 2013

More work being done to plug leaks. I'm quite pleased with the way things are turning out, and for Windows users I've been making some headway into making things work correctly. There's been work on GLSL and making the code more friendly to it — it's amazing watch shaders attached to a glGroup3D working on everything within it! In fact, lots of work has been done to make glGroup3Ds the go-to function when one wants to group a bunch of like-minded objects together.

August 29, 2013

Speed: I've been working on optimizing the rendering and have made fruitful progress. By my reckoning I've increased the speed of rendering loaded 3D models by nearly 50% on a Mac and for Windows have what I feel is speed parity with Mac. Other optimizations include using Xojo/RS2011's native OpenGL.commands wherever possible, which removes the overhead of all the calls to the GL module and does result in a measurable speed bump.

I need to temper the Windows bit by saying that the speed works only if the 3D model's vertices never change. If you do, the model needs to be "recompiled" and the time spent doing so will drag framerates greatly. This isn't as severe a problem with VBOs, but I'm still trying to figure out why VBOs don't work (at least on my virtual PC — I've had problems with other VBO examples compiled from C, so it might be just my machine).

There's still lots of work to be done, especially tracking down all the places where I can substitute OpenGL.commands. I also am looking at updating anything that still uses OpenGL code now removed from modern OpenGL.

August 17, 2013

It's been a while since I've been able to update this, but because Xojo has more mature Cocoa compiling I've been working on ensuring that it will compile for Cocoa. There were a few errors that were fixed: first off in places where Xojo is now more strict in syntax. Another fix ensures that antialiasing works properly. One final fix is that all textures are loaded with masks in order to conform to RGBA32 compatibility, which was an issue I had to correct because of Cocoa. At this point I feel that Carbon and Cocoa compiles correctly barring further testing (current testing being done in Xojo 2013r2 under OS X v10.6.8).

For those still running REAL Studio, the classes are still saved under REAL Studio 2011r2. If you're running Xojo and want Cocoa compiling, you should ensure your Build Settings are set to Cocoa.

A new addition has also been made: glMaterial now has methods for handling the setting of GLSL uniforms. This is important because the material can now send the proper texture index to the active GLSL shader so it can be rendered properly, especially if the shader was bound outside of where the material is attached. Special care was made so that shaders attached to a group3D level would use textures properly with any glElements contained within — it's hard to explain in words how important this is, but it's a major step in GLSL usage and allows the user that much more flexibility control over their objects. This will be more fully talked about in the documentation.

And speaking of documentation: the PDF has bookmarks and hyperlinks galore to make it easier to navigate quickly!

No word yet on multiple glSpaces — It has me stymied at the moment. I have a test app that I've been working on to test the issues.

February 26, 2013

Wanted to get something out sooner, but I've been working on how to get the classes to play nicely with multiple glSpaces — it's forced me to spend more time than I would like on creating small test apps to pinpoint issues. Still, there has been bug fixes under the hood for the rest of the classes, so I feel safe to say email me if you'd like the latest.

December 5, 2012

Just a few quick notes on what's being worked on:

• OBJ importer auto-triangulates n-gons.
• Can merge separate trimeshes into one - useful for faster rendering.
• User's Guide continues to expand and go into more depth.
• File importers handling a wider case of files from 3D apps - LOTS of work on 3DMFs!
• Grid drawing class.
• General speed improvements.
• More use of GLSL for rendering. Not just for speed but also for deprecated/removed OpenGL commands.

As always, if you want the latest please email me.

Test models that I've created for other REALbasic games can be downloaded here.

GL - v0.43

Download v0.43

• [NEW] User's Guide with code examples added to Reference Manual. This is a MASSIVE update aimed at clearing up usage. There's even a quick-start guide for those new to 3D in general.

• [UPDATE] glMaterial's Texture Property is now a pair of set/get Methods. This makes updating more transparent, as the explicit need to call InitPicture after assigning a Texture is removed.
  
• [UPDATE] glGroup3D handles texture binding the same as glTrimesh. This means that you can add textures at the glGroup level and have any glTrimesh use the textures if that glTrimesh does NOT have a Material (ie: Set the glTrimesh.Material = Nil). This will help speed up display of multiple glTrimeshes. glObject3Ds do not gain this benefit because their textures.
  
• [FIX] glTrimesh.Intersects now returns False if either itself or the other glElement is invisible.
  
• [FIX] glBounds3D will now report False during collision tests if its parent glElement3D is not visible.
  
• [FIX] IntersectTests.IntersectSphereSphere now works without any glElement attached.
  
• [FIX] gElement3D no longer crashes if its Material = Nil.
  
• [FIX] glSpace.ViewOrtho and glSpace.ViewPerspective are now Public Methods.
  
• [FIX] glTrimesh better safeguards against meshes that don't have UV coordinates.
  

As always, please refer to the included readme PDF for more information.

GL - v0.42

Download v0.42

• [NEW] glElement.GetPositionWorld and SetPositionWorld are used to read/modify the absolute world coordinates of an element. glElement.Position now affects its position within its Parent's local coordinate space that it's in. This is a fundamental shift that could break older code as Position no longer is understood as world coordinates, but it makes the underlying framework easier to maintain. If you need to retrieve world coordinates, glElement.PositionWorld will give you this.
  
• [NEW] gVector3D adds TimesVec3 and MultiplyVec3 - convenience methods takes each component and multiplies it by its corresponding input component: X = X * input.X, Y = Y * input.Y, Z = Z * input.Z.
  
• [NEW] Custom blending now has variable for setting the blend equation used. You need to pass the correct constant based on glBlendEquation.
  
• [NEW] glTextures now default to using trilinear filtering combined with anisotropic filtering. This results in better-looking textures. To do: Make this a modifiable option.
  
• [UPDATE] Sprites created by glTrimesh now have vertex normals.
  
• [FIX] glSpace.DrawGlow correctly binds texture.
  
• [FIX] glSpace.FindObject working again (broken in 0.41).
  
• [FIX] Screenshots can now be taken again (broken in 0.41).
  
• [FIX] Bounds3D better accounts for scaling.
  
• [FIX] Windows GLSL should be working correctly now.
  
• [FIX] Texture import on 32-bit pictures with an alpha now works correctly.
  
• [FIX] glSpace now allows user access to Open, Resized, and Render Events. Note that any user code added here happens AFTER the glSpace has run its own code.
  
• [FIX] Texture updating is now faster.
  
• [FIX] glElement3D.MoveFoward now works correctly with its orientation. Before this it would only move an element along its Z-axis regardless of orientation.
  

GL - v0.41

• [NEW] Updating glMaterial.Texture now updates the model's texture immediately. There is still an overhead for such updates, so update sparingly.
  
• [NEW] gTrimesh.AddShapeMaterial and AddShapeMaterials. These are convenience methods for creating sprites with already-created glMaterials.
  
• [NEW] glBillboard and glBillboards: creates a single or multiple camera-facing sprites. More flexible than glPointSprites but are slower to draw.
  
• [NEW] glPointSprites: creates camera-facing sprites with nothing more than a texture and a center point. If used, this bumps up the OpenGL version requirements to 1.5 or requires access to ARB_point_sprite. NOTE: Not fully tested on Windows.
  
• [NEW] Added Negate method to glVector3D, returning negation of that vector (or you can use the overloaded operator mentioned below).
  
• [NEW] Overloaded add, multiply, divide, subtract, and negate operators for glVector3D to make it easier to perform or read complex math with vectors (ie: vec1 + vec2 instead of vec1. add(vec2)).
  
• [NEW] glSpace.FindMouseRay: Given the mouse's X, Y coordinates, return a ray consisting of start point and direction (normalized and pointing into screen) vectors.
  
• [NEW] MatrixMath Module removes matrix stuff from glManager Module.
  

The fixes and updates are too numerous to list — please refer to the included readme PDF for more information.

GL - v0.35

Download v0.35

• [FIX] glCopyTexSubImage2D was incorrectly declared for RB2009r2 and lower (correctly declared for RB2009r3 and above, however).
  
• [FIX] MatrixMath.Mult4x4Matrix multiplication order switched. Previously multiplied B x A instead of the expected A x B.
  
• [NEW] MatrixMath Module removes matrix stuff from glManager Module.
• [FIX] glGroup3D.Opacity is now working.
  
• [FIX] Update to Quaternion.MultiplyBy. Older version may have been inaccurate.
  
• [FIX] OpenGL declares to built-in OpenGL Module now only for RB2009r3 and above.
  
• [FIX] Stability improvements to grabbing large screenshots.
  
• [FIX] Texturing mistakes cleaned up. Before, it was possible that a texture might be applied to the wrong object under certain circumstances. Note that more ' xes may be still forthcoming in this area.
  

Older versions:
> Download v0.31
> Download v0.2
> Download v0.1