Take it for what it's worth.
by Andrew Mac · in Torque 2D Professional · 11/08/2014 (10:13 am) · 13 replies
About a week ago I started a little personal project to build a 3D renderer to test some techniques in and play around with. I started building it on top of T2D since it's a simpler and cleaner code base and has torquescript, input, etc. I've reached the point where I'm ready to make a whole new repo and stop calling it a branch of Torque2D and fully implement the 3D stuff I have planned. I figured I'd leave my current branch in the state it is though and let you all know about it in case anyone wants to continue on where I left off and use these features for Torque2D. I'm about to start removing all the 2D stuff (other than GUI) because I don't want it, so it felt like a good time to release this to you guys and create a new repo.
What I did
What I did was take out the GL calls and replace them with calls to bgfx: github.com/bkaradzic/bgfx
Check the page for the full list of features, but here is the biggest reason I like it:
I also replaced a couple of functions in dgl. I replaced the calls for drawRectFill and drawText with calls to NanoVG: github.com/memononen/nanovg an anti-aliased vector graphics library. It has a number of nice features and you could follow my examples to expose these and make GUI controls out of them.
In order to draw images I needed shaders so there's a basic shader class in there which compiles and loads shaders written in the bgfx cross-platform shader language.
Lastly, I added assimp support: github.com/assimp/assimp and loaded and displayed a UV mapped and textured 3D model.
What I didn't do
I didn't remove all the GL calls. I didn't perfect all the GUI stuff yet, and I never touched spritebatcher or any of the stuff in the 2D folder. If you wanted to make this into a working copy of Torque2D you'd have to find all these random calls and features and replace them. There is a handful of missing features from dgl but I think they're quite trivial after image, font and filled rect.
Screenshots
Link To Branch
github.com/andr3wmac/Torque2D/tree/bgfx
Hopefully it will compile without any issues for you, assuming anyone is even interested. I made a folder called projects and there's a ConsoleProject in there that has the models, fonts, shaders and everything shown in the above screenshots except the cube demo because I replaced that code with the dwarf. Just set your working directory to ConsoleProject and you should be able to launch from Visual Studio. Oh, that reminds me, Visual Studio 2012 is the only project under the compilers folder that I added these libraries to. It shouldn't be too difficult to adapt other projects though, the project files can be edited in notepad, all the visual studio projects follow a similar format.
What I did
What I did was take out the GL calls and replace them with calls to bgfx: github.com/bkaradzic/bgfx
Check the page for the full list of features, but here is the biggest reason I like it:
Quote:
Supported rendering backends:
Direct3D 9
Direct3D 11
OpenGL 2.1
OpenGL 3.1+
OpenGL ES 2
OpenGL ES 3.1
Supported platforms:
Android (14+)
asm.js/Emscripten (1.25.0)
iOS
Linux
Native Client (37)
OSX (10.9)
RaspberryPi
Windows (XP, Vista, 7, 8, 10)
I also replaced a couple of functions in dgl. I replaced the calls for drawRectFill and drawText with calls to NanoVG: github.com/memononen/nanovg an anti-aliased vector graphics library. It has a number of nice features and you could follow my examples to expose these and make GUI controls out of them.
In order to draw images I needed shaders so there's a basic shader class in there which compiles and loads shaders written in the bgfx cross-platform shader language.
Lastly, I added assimp support: github.com/assimp/assimp and loaded and displayed a UV mapped and textured 3D model.
What I didn't do
I didn't remove all the GL calls. I didn't perfect all the GUI stuff yet, and I never touched spritebatcher or any of the stuff in the 2D folder. If you wanted to make this into a working copy of Torque2D you'd have to find all these random calls and features and replace them. There is a handful of missing features from dgl but I think they're quite trivial after image, font and filled rect.
Screenshots
Link To Branch
github.com/andr3wmac/Torque2D/tree/bgfx
Hopefully it will compile without any issues for you, assuming anyone is even interested. I made a folder called projects and there's a ConsoleProject in there that has the models, fonts, shaders and everything shown in the above screenshots except the cube demo because I replaced that code with the dwarf. Just set your working directory to ConsoleProject and you should be able to launch from Visual Studio. Oh, that reminds me, Visual Studio 2012 is the only project under the compilers folder that I added these libraries to. It shouldn't be too difficult to adapt other projects though, the project files can be edited in notepad, all the visual studio projects follow a similar format.
About the author
#2
11/10/2014 (11:37 am)
Andrew Mac delivers! Awesome stuff, man. Definitely going to test this soon.
#3
Let me know if you move forward with it. I've become quite familiar with bgfx and exchange emails with the creator so I can certainly offer advice on finishing it up, but at the same time, his tutorials are great and it's an easy to use library so I'm sure you'll have no issues.
@ Simon
Thanks, I wouldn't get too excited about it doing much. What you see in the screenshots is pretty much the extent of it's abilities, though I'm sure other GUI controls would work. It's a foot in the door anyway =) hence the title of "Take it for what its worth" haha.
11/10/2014 (11:43 am)
@ MikeLet me know if you move forward with it. I've become quite familiar with bgfx and exchange emails with the creator so I can certainly offer advice on finishing it up, but at the same time, his tutorials are great and it's an easy to use library so I'm sure you'll have no issues.
@ Simon
Thanks, I wouldn't get too excited about it doing much. What you see in the screenshots is pretty much the extent of it's abilities, though I'm sure other GUI controls would work. It's a foot in the door anyway =) hence the title of "Take it for what its worth" haha.
#4
Many recent T2D developments were the direct result of Mike and me taking turns at a particular problem.
11/10/2014 (12:04 pm)
@Andrew : You build one step, another fellow with a different focus and interests builds another one, that's the beauty of open-source!Many recent T2D developments were the direct result of Mike and me taking turns at a particular problem.
#5
Most Guis work fine, I'm currently replacing the SceneWindow rendering code.
Shouldn't take more than a week to rework the engine to make BGFX calls instead of stock GL calls + add shader assets. And as we know, when we think something should take a week in coding-land, it's probably going to take 6 or 18.
One weird thing is that BGFX apparently doesn't support full-screen, which I found quite baffling! Didn't test it out yet but it says that it's on the developer's TO-DO list.
One cool thing though, which I won't even think about attempting at the moment, is how BGFX supports multiple rendering windows, which could be very interesting for editors.
11/25/2014 (4:56 pm)
Been messing around with it for the past 2 days or so.Most Guis work fine, I'm currently replacing the SceneWindow rendering code.
Shouldn't take more than a week to rework the engine to make BGFX calls instead of stock GL calls + add shader assets. And as we know, when we think something should take a week in coding-land, it's probably going to take 6 or 18.
One weird thing is that BGFX apparently doesn't support full-screen, which I found quite baffling! Didn't test it out yet but it says that it's on the developer's TO-DO list.
One cool thing though, which I won't even think about attempting at the moment, is how BGFX supports multiple rendering windows, which could be very interesting for editors.
#6
You're right. That is rather odd. It seems trivial compared to the other things he's done. I imagine though that on platforms like Android it would be fullscreen automatically due to the nature of the platform. Not sure what the hold up would be on PC fullscreen.
Let me know if there's any sticking points you hit. There are a few odd things about BGFX ( view number, sorted draw call bucketing ) that can be quite powerful when you figure out how to use them to your advantage.
11/26/2014 (5:40 am)
I was just going to say BGFX_RESET_FULLSCREEN but then I checked it and:Quote:
/// - `BGFX_RESET_FULLSCREEN` - Not supported yet.
You're right. That is rather odd. It seems trivial compared to the other things he's done. I imagine though that on platforms like Android it would be fullscreen automatically due to the nature of the platform. Not sure what the hold up would be on PC fullscreen.
Let me know if there's any sticking points you hit. There are a few odd things about BGFX ( view number, sorted draw call bucketing ) that can be quite powerful when you figure out how to use them to your advantage.
#7
I'm experimenting with the View thing now, didn't understand it at first, I think I got it now.
I will spam the chat room if ever I'm stuck, don't you worry!
11/26/2014 (3:43 pm)
I'm not rushing it, just trying to figure it out in my spare time.I'm experimenting with the View thing now, didn't understand it at first, I think I got it now.
I will spam the chat room if ever I'm stuck, don't you worry!
#8
The depth value supplied there has no actual impact on the depth that's drawn, it's just another number that's used to sort the draw calls before issuing them. This way, you can calculate a depth value for your objects and count on them being sorted back-to-front or front-to-back based on however you order it.
Both of these mechanisms should lend themselves well to 2D things. You can do layers and ordering pretty easily.
11/27/2014 (5:23 am)
Yeah, view numbers are pretty awesome when you get the hang of them. It's a great way to layer things without needing to worry about the order you submit things. Submit whatever you want in any order to view 0 or 1 and you can count on view 1 rendering after view 0. Another useful similar sorting mechanism is supplying a depth value with the submit call:Quote:
/// Submit primitive for rendering into single view.
///
/// @param _id View id.
/// @param _depth Depth for sorting.
/// @returns Number of draw calls.
///
uint32_t submit(uint8_t _id, int32_t _depth = 0);
The depth value supplied there has no actual impact on the depth that's drawn, it's just another number that's used to sort the draw calls before issuing them. This way, you can calculate a depth value for your objects and count on them being sorted back-to-front or front-to-back based on however you order it.
Both of these mechanisms should lend themselves well to 2D things. You can do layers and ordering pretty easily.
#9
The one thing thing that's got me stumped though is that I render the GUI in view 1 and the contents of a Scenewindow in View 2. Everything works fine until I push a dialog (i.e. the console). The console is displayed on top of the stack but the SceneWindow renders above it; I don't get how to tell it to render View 2 in-between layers of View 1.
11/27/2014 (5:36 am)
Nice explanation!The one thing thing that's got me stumped though is that I render the GUI in view 1 and the contents of a Scenewindow in View 2. Everything works fine until I push a dialog (i.e. the console). The console is displayed on top of the stack but the SceneWindow renders above it; I don't get how to tell it to render View 2 in-between layers of View 1.
#10
I saw this issue coming when I first start using it. I'm not sure how T2D sorts GUI controls, but assuming they draw them in order, I think the best approach would be: Keep drawing gui controls on view 0 until you hit scenewindow. Draw all the scenewindow contents on view 1. draw the remaining gui controls on view 2. This way your scenewindow is sandwiched between the two gui layers and itll allow them to render over and under your scenewindow.
Should note, I've spoke with branimir about it, and views are nothing more than a numeric ordering system (same with the depth value), so there's no overhead associated with spreading across multiple views.
Alternatively you could put everything on a single view and utilize the depth value I spoke of to control sorting them properly.
If you haven't read it yet this is a great resource on the draw call ordering system he has in place (his is a bit different, but same concept):
realtimecollisiondetection.net/blog/?p=86
11/27/2014 (5:59 am)
The view numbers render in ascending order. So, first all of view 0, then all of view 1, then all of view 2, etc. You can't control the order the views render or rendering pieces of them. This leaves you in a situation where you have to either put GUI above the scenewindow (view 2) or below the scene window (view 0). I saw this issue coming when I first start using it. I'm not sure how T2D sorts GUI controls, but assuming they draw them in order, I think the best approach would be: Keep drawing gui controls on view 0 until you hit scenewindow. Draw all the scenewindow contents on view 1. draw the remaining gui controls on view 2. This way your scenewindow is sandwiched between the two gui layers and itll allow them to render over and under your scenewindow.
Should note, I've spoke with branimir about it, and views are nothing more than a numeric ordering system (same with the depth value), so there's no overhead associated with spreading across multiple views.
Alternatively you could put everything on a single view and utilize the depth value I spoke of to control sorting them properly.
If you haven't read it yet this is a great resource on the draw call ordering system he has in place (his is a bit different, but same concept):
realtimecollisiondetection.net/blog/?p=86
#11
I've worked out the logic "on paper", tonight we'll see if it works!
Thanks Andrew, appreciate your help.
11/27/2014 (8:35 am)
Thank you for the pointer, it unlocked the problem! I'm going with your suggested approach, which should also work for multiple SceneWindows.I've worked out the logic "on paper", tonight we'll see if it works!
Thanks Andrew, appreciate your help.
#12
11/27/2014 (11:08 pm)
Blah, now it seems that the NanoVG context is linked to a single view. Gonna have to dig much deeper than I thought, as always :)
#13
You could also dodge all of this by doing everything on the same view. There's a command you need to call on views to make them work with NVG, setViewSeq, which sets the view to sequential drawing. With this is place on a view each command you call will be executed in the order you call it rather than sorted internally. I don't like this for the 3D stuff I'm doing as I like taking advantage of his sorting algorithms for front-to-back sorting to reduce overdraw, but for 2D I don't think it's as big of a concern.
I do feel like to get the most of out of bgfx and nanoVG you should probably try to stick with the first option with multiple NVG contexts.
11/28/2014 (9:55 am)
Haha, yeah I thought of that last night as well. I don't think it's a huge deal. You should be able to establish two NVG contexts on two views. Then just target the different one based on which layer of GUI you're doing. I'm not positive of the overhead of doing that, likely that both contexts will maintain a buffer for what they're drawing. Still not a huge amount of overhead in my opinion but maybe it would be on mobile platforms? Something to keep in mind moving forward.You could also dodge all of this by doing everything on the same view. There's a command you need to call on views to make them work with NVG, setViewSeq, which sets the view to sequential drawing. With this is place on a view each command you call will be executed in the order you call it rather than sorted internally. I don't like this for the 3D stuff I'm doing as I like taking advantage of his sorting algorithms for front-to-back sorting to reduce overdraw, but for 2D I don't think it's as big of a concern.
I do feel like to get the most of out of bgfx and nanoVG you should probably try to stick with the first option with multiple NVG contexts.
Associate Mike Lilligreen
Retired T2Der