Canvas
- ajs15822
- OGRE Expert User
- Posts: 570
- Joined: Mon Jan 02, 2006 2:05 am
- Location: Texas
- x 2
- Contact:
Canvas
Hey Ogre3D, it's been a while. I thought I'd share a little something I've been working on.
What: A super-fast, lightweight, 2D-rendering engine for Ogre3D. To be used for powering simple HUDs or basic interface libraries.
Why: Existing solutions seemed a bit inefficient and I felt like tackling the issue. My implementation is able to batch all rendering into one operation, regardless of document complexity, without using any real-time texture caching.
How: The secret sauce is Atlas, a programmatic texture atlas that can pack font glyphs of multiple fonts and texture assets into a single texture. Assets are pre-loaded into an Atlas, eliminating the need for material-switching in a Canvas (allowing me to get the batch count down to one).
Screenshot: (click for bigger)
Here's a screenshot of the packed Atlas texture that was generated at run-time (in about 0.03s) for the demo. It contains 4 font faces and 5 font sizes (for a total of 500 glyphs) and a single texture (the logo). Please note that most of the unused space is due to POT limitations on texture-sizes. (click for bigger)
The demo itself is also a work of love; everything is data-driven, it can parse "<font></font>" tags (so that you can specify inline font styles), and I also wrote a simple multi-font text-layout implementation (see TextFlowElement).
Download the demo here.
The source is LGPL, non-platform-specific (feel free to port). All you need to build is MSVC8 and the OgreSDK (the only other dependency, FreeType, is included).
Download the source here.
I'm welcome to questions, comments, and critique.
What: A super-fast, lightweight, 2D-rendering engine for Ogre3D. To be used for powering simple HUDs or basic interface libraries.
Why: Existing solutions seemed a bit inefficient and I felt like tackling the issue. My implementation is able to batch all rendering into one operation, regardless of document complexity, without using any real-time texture caching.
How: The secret sauce is Atlas, a programmatic texture atlas that can pack font glyphs of multiple fonts and texture assets into a single texture. Assets are pre-loaded into an Atlas, eliminating the need for material-switching in a Canvas (allowing me to get the batch count down to one).
Screenshot: (click for bigger)
Here's a screenshot of the packed Atlas texture that was generated at run-time (in about 0.03s) for the demo. It contains 4 font faces and 5 font sizes (for a total of 500 glyphs) and a single texture (the logo). Please note that most of the unused space is due to POT limitations on texture-sizes. (click for bigger)
The demo itself is also a work of love; everything is data-driven, it can parse "<font></font>" tags (so that you can specify inline font styles), and I also wrote a simple multi-font text-layout implementation (see TextFlowElement).
Download the demo here.
The source is LGPL, non-platform-specific (feel free to port). All you need to build is MSVC8 and the OgreSDK (the only other dependency, FreeType, is included).
Download the source here.
I'm welcome to questions, comments, and critique.
- NoodlesOnMyBack
- Goblin
- Posts: 200
- Joined: Tue Feb 05, 2008 4:14 am
- Location: Buenos Aires, Argentina
- Contact:
- Jerky
- Orc Shaman
- Posts: 791
- Joined: Wed Mar 02, 2005 4:13 am
- Location: Springville, Utah
- Contact:
- AshMcConnell
- Silver Sponsor
- Posts: 605
- Joined: Fri Dec 14, 2007 11:44 am
- Location: Northern Ireland
- x 16
- Contact:
- betajaen
- OGRE Moderator
- Posts: 3447
- Joined: Mon Jul 18, 2005 4:15 pm
- Location: Wales, UK
- x 58
- Contact:
-
- Halfling
- Posts: 45
- Joined: Mon Apr 23, 2007 1:01 pm
- Contact:
- Praetor
- OGRE Retired Team Member
- Posts: 3335
- Joined: Tue Jun 21, 2005 8:26 pm
- Location: Rochester, New York, US
- x 3
- Contact:
- ajs15822
- OGRE Expert User
- Posts: 570
- Joined: Mon Jan 02, 2006 2:05 am
- Location: Texas
- x 2
- Contact:
Heh, you're right-- it looks like an experiment in typography.Kojack wrote:hehe, that atlas texture looks almost artistic.
Yup, the packing algo is binary space partitioning-- I needed something that could balance results with performance. If you have any suggestions for better algorithms to try, please share!lf3thn4d wrote:Pretty neat. Looking at the atlas, it looks like bsp packing to me. Not very efficient imho, but good enough
Absolutely, it was designed for frequent geometry updates.AshMcConnell wrote:Is it suitable for quickly changing stuff
Similar to Ogre's BillboardSet, Canvas keeps a pool of quads around and resizes the index/vertex buffers only when it needs to. Confining the rendering to indexed quads allows us to decrease the number of vertices required (speeding up vertex buffer updates) and also to optimize index buffer updates (it is only updated during buffer resize).
HawtAshMcConnell wrote:PS. Just tested the demo and it ran at ~5000fps (yes FIVE thousand!)
Rofl.ValentinGalea wrote:I for one, welcome our new overlord Atlas!
- Kentamanos
- Minaton
- Posts: 980
- Joined: Sat Aug 07, 2004 12:08 am
- Location: Dallas, TX
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
- Frenetic
- Bugbear
- Posts: 806
- Joined: Fri Feb 03, 2006 7:08 am
Say, what happens when the Atlas gets too big? Looking at the source, it seems the Atlas expands infinitely, whereas I think most current cards only support 2048x2048 textures, the newer fancier ones do 4096, and older or on-board ones can only do 1024. Also, some on-board cards don't like large non-square (eg. 512x1024) textures... so a feature for general texture-size constraints, maybe an error-check or something, would be nice. And maybe the ability to "reserve()" a certain size ala std::vector.
I suppose I can use several Canvas+Atlases if I expect to be using a crap-ton of textures? I'll probably replace my own GUI-drawing code with this (improving my own code would be re-inventing the wheel now) and I have lots of fonts and text, lots of background images, lots of icons, etc. so going beyond the max texture size my card supports is almost certain.
Oh, and the fonts in my app are (supposed to be) user-customizable. Dynamically regenerating the fonts shouldn't be too hard, right? (This feature does not need real-time performance, of course)
Lastly, it bugs me that you don't use the mWhatever member-variable convention... everything else is so far above my highest standards, that this tiny issue stands out...
I suppose I can use several Canvas+Atlases if I expect to be using a crap-ton of textures? I'll probably replace my own GUI-drawing code with this (improving my own code would be re-inventing the wheel now) and I have lots of fonts and text, lots of background images, lots of icons, etc. so going beyond the max texture size my card supports is almost certain.
Oh, and the fonts in my app are (supposed to be) user-customizable. Dynamically regenerating the fonts shouldn't be too hard, right? (This feature does not need real-time performance, of course)
Lastly, it bugs me that you don't use the mWhatever member-variable convention... everything else is so far above my highest standards, that this tiny issue stands out...
- detox
- Greenskin
- Posts: 103
- Joined: Thu Sep 07, 2006 1:13 am
- Location: Ohio, USA
- Contact:
- metaldev
- Orc Shaman
- Posts: 761
- Joined: Thu Mar 17, 2005 11:56 pm
- Location: Boston
- x 15
- Contact:
-
- Gnome
- Posts: 341
- Joined: Thu May 13, 2004 4:52 pm
- Location: Wales - UK
- neocryptek
- Gnome
- Posts: 335
- Joined: Sat Mar 01, 2003 11:21 pm
- Location: Idaho, USA
- Contact:
- Fuinelen
- Halfling
- Posts: 86
- Joined: Thu Mar 31, 2005 7:42 am
- Location: Martinique
- Contact:
Linux port
First of all, thanks a lot for sharing
I'm trying to port it to linux right now (using code::blocks) and I got so far as to only receive this lonely error :
any ideas what I missed?
I'm trying to port it to linux right now (using code::blocks) and I got so far as to only receive this lonely error :
Code: Select all
Canvas - May 12th 2008/Canvas/Source/Atlas.cpp||In member function ‘void Atlas::pack(ComputationVector&)’:|
Canvas - May 12th 2008/Canvas/Source/Atlas.cpp|385|error: no matching function for call to ‘sort(__gnu_cxx::__normal_iterator<ComputationRect**, std::vector<ComputationRect*, std::allocator<ComputationRect*> > >, __gnu_cxx::__normal_iterator<ComputationRect**, std::vector<ComputationRect*, std::allocator<ComputationRect*> > >, Atlas::pack(ComputationVector&)::compare)’|
- scriptkid
- Bronze Sponsor
- Posts: 88
- Joined: Fri Jun 25, 2004 8:16 pm
- Location: The Hague, Netherlands
- Contact:
Hey there,
looks nice I browsed through the code and liked your apprauch of using states for painting formatted text.
As you mention, you wrote it to power simple HUD elements. Does that mean that users should combine your system with a more full-blown system in order to create an options screen or an inventory, for example? Or are you going to add more widget types?
Good luck anyway
looks nice I browsed through the code and liked your apprauch of using states for painting formatted text.
As you mention, you wrote it to power simple HUD elements. Does that mean that users should combine your system with a more full-blown system in order to create an options screen or an inventory, for example? Or are you going to add more widget types?
Good luck anyway
Check out my released 3D snake game using Ogre!
-
- Goblin
- Posts: 254
- Joined: Tue Feb 13, 2007 5:33 am
Wow, ajs15822! Very good job. Well done, as always.
Suggestions:
* I think quite a lot of the "demo" source should go into the main library. The Document, Element, ImageElement, Parser and TextFlowElement feel like "core" classes, IMO.
* Add text justification to TextFlowElement.
* Add serialization support. Creating an editor with that would be a piece of cake.
* Multitexture support. Even if this increases the batch count, is the only way to provide nearly limitless flexibility.
* AnimatedImageElement. 'Nuff said.
* Primitive drawing: point, line, circle, square, polyline. Maybe a fill function, too.
I had to reinstall my system a few days ago, but if I manage to set my development environment soon enough, I'll gladly help with these.
Suggestions:
* I think quite a lot of the "demo" source should go into the main library. The Document, Element, ImageElement, Parser and TextFlowElement feel like "core" classes, IMO.
* Add text justification to TextFlowElement.
* Add serialization support. Creating an editor with that would be a piece of cake.
* Multitexture support. Even if this increases the batch count, is the only way to provide nearly limitless flexibility.
* AnimatedImageElement. 'Nuff said.
* Primitive drawing: point, line, circle, square, polyline. Maybe a fill function, too.
I had to reinstall my system a few days ago, but if I manage to set my development environment soon enough, I'll gladly help with these.
- Nauk
- Gnoll
- Posts: 653
- Joined: Thu May 11, 2006 9:12 pm
- Location: Bavaria
- x 36
- Contact:
Very usefull AJ, good work there
ARTIFEX TERRA 3D - Artist-friendly, free and easy WYSIWYG realtime outdoor scene Editor & Painter
New loader now with Ogre::Terrain support: Addons for Artifex on SourceForge
MOC - Minimal Ogre Collision & Mousepicking
Simple TerrainMaterialGenerator for the use of standard Ogre material with Ogre::Terrain
Support me on Patreon
-
- Gremlin
- Posts: 168
- Joined: Wed Sep 19, 2007 1:19 pm
- Location: singapore
- x 3
- nikki
- Old One
- Posts: 2730
- Joined: Sat Sep 17, 2005 10:08 am
- Location: San Francisco
- x 13
- Contact: