Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  zShapes - Resolution Independent Curve Rendering  (Read 14687 times)
0 Members and 1 Guest are viewing this topic.
Offline Spasi
« Posted 2006-09-02 04:32:14 »

Hi everyone, this is the first version of zShapes (~3.5MB, includes samples).

WHAT IT IS [BRIEFLY]

zShapes is a tool that allows you to render resolution independent vector graphics in real-time on your GPU. The tool can convert any Java2D shape to a set of triangles that can later be rendered with OpenGL. Antialiasing is also supported.

HOW IT STARTED

zShapes started as a little weekend project. I had been impressed by UlfJack's Thinlet port to LWJGL, except one thing: it was lacking fonts. So I was thinking "now he's going to have to do the whole texture thing, what a bunch of crap that technique is". He was going to do it, I'm doing it in Marathon, everyone else is doing it. My next thought, "it should be possible to do this right with today's GPUs". So I decided that it was going to be a "font rendering" weekend. Turned out to be a month of course. Wink

WHAT IT IS

After an exhaustive search of my paper library, I came across a really interesting paper:

Resolution Independent Curve Rendering using Programmable Graphics Hardware, by Charles Loop and Jim Blinn

The paper describes a technique that can be used to render any quadratic Bezier curve using a single drawing primitive: a triangle and a simple function that is evaluated per-pixel. Basically zShapes is an implementation of this technique. It is a simple library at it's core, but is accompanied by an editor, that provides a UI to do the shape->triangle conversion, and a viewer, that renders the shapes with OpenGL.

FEATURES [Editor]

The primary function in the Editor is the shape triangulation. You give it any Java2D shape and it outputs the generated triangles. It's not a simple delaunay triangulation, a lot of work is done to remove overlaps and clean-up the mesh, and a lot of triangle breaking & triangle additions are needed to support the antialiasing implementation.

There are two ways to produce work for the Editor:

- A simple dialog allows you to create some text using any font supported by the system. The text outline (as a Java2D shape) is then converted to triangles.
- Any SVG file can be imported and used as a Java2D shape. I use the Batik SVG Toolkit for this.

After a triangulation, the generated mesh can be exported to file.

The Editor has a few other features that were added to make it more user friendly:
    - Easy navigation/zooming
    - A console that logs what the triangulator is doing
    - Various overlays for debugging (shape overlay, points, statistics, etc)

FEATURES [Viewer]

The Viewer is an LWJGL application that renders the generated meshes. It provides basic navigation/zooming and support for toggling antialiasing. What's important though is the rendering implementations. The technique is supposed to work with fragment shaders, but I've implemented the following variations:

With no antialiasing
    - NV_register_combiners (GeForce 3 or better)
    - ATI_fragment_shader (ATI 8500 or better)
    - GLSL fragment shaders (GeForce FX, ATI 9500 or better)

With antialiasing
    - GLSL fragment shaders, using shader derivatives (GeForce FX, ATI X1x00 or better)
    - GLSL fragment shaders, using texture derivatives (ATI 9x00, ATI Xx00)

It was a little difficult to overcome the accuracy limitations of NV_RCs and ATI_FS, but it's usable now by many more users.

ADVANTAGES

- It's a resolution independent technique (duh). You can zoom in as much as you want and it never produces aliasing. The only limitation is GPU accuracy, that can cause some artifacts in extreme cases (when zooming, also the non-GLSL paths are more sensitive).
- Rendering is very fast. Also, if compared to the alternative (massive triangle tesselation), there's a very nice balance between vertex and fragment processing.
- It has tiny memory overhead. The meshes are generally low-poly (depending on the shape of course) and the geometry data is only 3 floats per vertex.
- Antialiasing is done in the shader using derivatives. That means it doesn't need multisampling to work, neither POLYGON_SMOOTH. It's very fast too.

DISADVANTAGES

- No shape coloring/shading is currently supported. The renderer only generates an alpha value (in shape or out of shape). Basic shading could be very easily added though (colors, gradients, etc).
- The Editor triangulation is quite slow.
- Cubic curves are currently approximated with quadratics. Depending on the error threshold, many unnecessary triangles may be generated.
- Antialiasing is quite poor is certain cases.
- The Editor currently runs on Windows & Linux only. MacOSX is also supported for the Viewer.

FUTURE WORK

There are a lot of improvements that can be done, but I don't think I'll spend much more time on this. Given enough interest, I could set up a project on SF for others to contribute, though. Given no interest, I'll post the source here as-is. Anyway, my e-mail is spasi [at] zdimensions [dot] gr. The list:

Tool improvements
    - The triangulation is currently done using Triangle, a powerful and robust delaunay triangulator, which is unfortunately written in C. This limits the Editor to Windows & Linux only. A Java port of Triangle, or any other decent Java-based triangulator would be nice to have. Also, it would more easily allow the library to be used at runtime.
    - All the algorithms are almost brute-force and "linear" in design. Virtually every part of the implementation can be sped up and optimized memory-wise.
    - The Editor currently misses a way to produce a "font map", that is, a glyph list that can used to render any text in a GL application. I'll do this soon anyway.
    - Support for display lists and VBO should be added in the Viewer.
    - Support for basic SVG coloring features may be added to the Viewer.
    - It's not much of library as-is. Both the triangulator and the renderers should be made more general.
    - Support for JOGL rendering could be added.

Technique improvements
    - The RICR paper also describes how to render cubic curves. My math skills are too limited for that though, I couldn't understand it and also didn't have time to understand it. It would be a great addition though. Especially for SVG shapes that are heavy on cubic curvers, a significant reduction in triangle count could be achieved (a tradeoff for a few more fragment shader instructions).
    - I don't think I've completely understood the way antialiasing is supposed to work. Basically external triangles are added to the mesh, but that has forced me to implement more than one hack to overcome quality issues (also the triangle count is increased unnecessarily). I may contact the paper authors about this.
    - Subpixel antialiasing could be implemented.
    - Another interesting technique that could be explored is GLSL Conics.

SCREENSHOTS (Editor | Viewer, click for hi-res)

A text example:


An SVG example:


That's it, C&C welcome.
Offline Spasi
« Reply #1 - Posted 2006-09-02 16:44:13 »

Sorry guys, I had no time for tests and the original zShapes didn't work on Java 5.0. It is fixed now.
Offline weston

Junior Member





« Reply #2 - Posted 2006-09-02 18:10:47 »

That's really cool - works on my java 5.0.

for(int i = 1; i > 0; i++)
{
System.out.println(i+" cups of java downed");
}
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Spasi
« Reply #3 - Posted 2006-09-02 20:13:04 »

Added support for ARB_vertex_program in the NV_RC & ATI_FS paths for cards with no GLSL support (usually laptops with ancient drivers). Special thanks to Akis.
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 74
Projects: 15


★★★★★


« Reply #4 - Posted 2006-09-02 21:15:21 »

thats really nice runs really good here on linux, jre5.

could it possibly be turned into a font rendering library that can be used in games or does it take too much resources to be used in game?
Offline Spasi
« Reply #5 - Posted 2006-09-02 22:42:50 »

That's the plan. General purpose font rendering is the primary target, but I'll have to implement it first and see how good or bad it scales. I'll need help to make it a truly general library though.
Offline elias

Senior Member





« Reply #6 - Posted 2006-09-05 21:16:23 »

This is great stuff - I saw the paper while reading about Xgl and how thet might exploit current GPUs for accelerating desktop rendering. I wanted to implement it for our own games but never got around to do it (partly because of the GLSL requirement, which you seemed to have offset by a card generation or two).

 - elias

Offline Spasi
« Reply #7 - Posted 2006-09-10 19:54:46 »

Made some progress with general text rendering:



The above is 3 Lorem Ipsum paragraphs as well as some english, chinese, romanian, brazilian and greek text, all rendered at ~280 fps with fragment shaders + antialiasing.

Turned out quite nice, but there are many issues yet to be solved. I'll post details some other day. I will also update the program .zip when I have a decent UI for the new functionality. Source code will be posted when most of the significant issues are solved and some performance optimizations made.
Offline thijs

Junior Member




Lava games rock!


« Reply #8 - Posted 2006-09-10 20:40:14 »

Sweet!
Actually this is quite similar to an issue I kept pushing down my todo list Wink I'll certainly give it a try when I catch up!

<a href="http://www.dzzd.net">3DzzD!</a>
<a href="http://www.arcazoid.com">Arcazoid!</a>
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 74
Projects: 15


★★★★★


« Reply #9 - Posted 2006-09-11 00:21:05 »

looking great and even better than before  Grin
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Spasi
« Reply #10 - Posted 2006-09-12 12:25:02 »

Implemented italicized, underlined and striked though text rendering. All three are dynamic (a single glyph source is used). The italic angle is also customizable (a simple shear ratio). Examples:

OriginalItalic
UnderlineStrikethrough
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #11 - Posted 2006-09-12 12:53:15 »

Neat stuff.  Grin

However, in a game I tend to have bits of text floating around all over the place and at different layers. Isn't this going to require lots of binding and unbinding of fragment programs and drag the performance down somewhat? Or am I overestimating the actual cost of switching between shaders?

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Spasi
« Reply #12 - Posted 2006-09-12 13:27:14 »

The standard technique requires binding and unbinding of textures, so it has equivalent state changing cost. Also note that in order to switch fonts you don't have to change anything (just call a different display list), whereas with the standard technique you still have to change the texture. Btw, the above examples, including italics, use exactly the same shader (non-italic is italic with a zero angle Smiley). Overall, state changing should not be a problem.

It still has several disadvantages that I will explain in depth in a later post, and it IS slower than using textures of course. But that's totally acceptable considering what you get in exchange.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #13 - Posted 2006-09-12 13:41:55 »

I always thought that a shader change was more expensive than a texture bind? It'd be great if you could detail some of the disadvantages, although from the quality I expect its a perfectly good tradeoff in most cases.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Spasi
« Reply #14 - Posted 2006-09-12 14:25:08 »

I always thought that a shader change was more expensive than a texture bind?

It is, but not by much. Anyway, the relative cost of a state change is not important, but the pipeline stall caused by *any* state change, is. So, I'd argue that modern engines should struggle to minimize the *number* of state changes and not just order by the most expensive state. This can be achieved with slightly more complex shaders and techniques like pseudo-instancing (I'm using both).

It'd be great if you could detail some of the disadvantages, although from the quality I expect its a perfectly good tradeoff in most cases.

The disadvantages in a few words:

- Low quality without AA
- Low quality at small font sizes, even with AA (may be fixable in the AA case)
- AA requires SM2.0 hardware
- AA requires a texture bind on non-SM3.0 ATI hardware
- Huge memory requirements for large unicode ranges (chinese glyphs are particularly heavy)
- Display lists are memory heavy (lots of duplicate vertices) and cannot take advantage of post-transform cache optimization.
- With VBOs indexing can be done (2.5 times lower memory requirements, even below the standard technique), but would require more state changes at runtime.
- With indexed VBOs and large unicode ranges, either 32bit indices would have to be used (bad), or even more state changes would be required.

Depending on the developer needs, some of the above are not issues and some may be mitigated by decent tools and clever rendering techniques.
Offline bitshit

Junior Member




Java games rock!!


« Reply #15 - Posted 2006-09-12 17:38:26 »

It sounds very impressive, but I have some questions:

- I couldn't find the thinlet port to lwjgl you mentioned in your first post on google or these forums, do you have a link? (as such a leightweight lwjgl gui sounds interesting!)
- You also mentioned you found it disapointing that it used font rendering to textures, but isn't this totally acceptable for use in games?
- I understand it will be a generic shape engine? Will you support fillers / textures for shapes?

Anyway, keep up the good work!
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 74
Projects: 15


★★★★★


« Reply #16 - Posted 2006-09-12 18:09:50 »

I couldn't find the thinlet port to lwjgl you mentioned in your first post on google or these forums, do you have a link? (as such a leightweight lwjgl gui sounds interesting!)

thinlet port is being done by UlfJack, its not released yet, but i hear its very close to being finished.
Offline Spasi
« Reply #17 - Posted 2006-09-12 18:38:43 »

Hi bitshit,

I couldn't find the thinlet port to lwjgl you mentioned in your first post on google or these forums, do you have a link? (as such a leightweight lwjgl gui sounds interesting!)

As kapta said, it's going to be released soon. I'm eager to try it too.

You also mentioned you found it disapointing that it used font rendering to textures, but isn't this totally acceptable for use in games?

The little demo I had tried didn't have font rendering at all. It just gave me the initial inspiration to do something about it. And yes, font rendering with textures is totally acceptable for games and, as I said in my first post, I'm doing it in my engine.

I understand it will be a generic shape engine? Will you support fillers / textures for shapes?

Well, the primary target was to explore a new way to render real-time text. Thanks to the Batik library, SVG support was easy to add, so yes, it is a generic shape renderer*. But only the shape outline of an SVG graphic is used. Adding support for fillers/gradients/textures/whatever, or even supporting the whole SVG thing, would be a huge undertaking. AmanithVG is a great library that supports almost everything, but it's commercial and it's a C library.

Nevertheless, I'm hoping that the final library would make it easy for the users to add their own shading. Simple fills and gradients are easy, so I'll probably provide some default implementations. More complicated stuff will have to be done at a higher level.

* Btw, the triangulation "primitive" is a Java2D Shape. Anything that can be converted to a Java2D Shape is applicable, not only fonts and SVG graphics.
Offline bitshit

Junior Member




Java games rock!!


« Reply #18 - Posted 2006-09-13 09:51:08 »

thanks for the info!

i checked out AmanithVG and it looks nice. Though it's not clear to me how your implementation differs from theirs? they both seem to render SVG shapes & operations on the GPU using shaders (which is the openVG standard?)
 
i don't know too much about this, but what would make textured shapes etc be so hard to implement? from the looks of it most of the work is already done...
Offline Spasi
« Reply #19 - Posted 2006-09-13 14:10:44 »

Though it's not clear to me how your implementation differs from theirs? they both seem to render SVG shapes & operations on the GPU using shaders (which is the openVG standard?)

There are big differences:

At the low level, my implementation takes advantage of the technique in the paper I mentioned in my first post, which allows rendering of a quadratic curve segment using a single triangle (resulting in significant triangle count reduction). AFAIK, AmanithVG does full tessellation. Which is understandable, considering the hardware they target.

At the high level, well, my implementation does *not* even try to understand the SVG graphic. I only added support for SVG to show the potential of the technique. On the other hand, AmanithVG has amazing support for SVG rendering: fills, strokes, paths, patterns, scissoring, filters, blend modes, etc.

Two good examples are the fort.svg and lwjgl.svg from the samples folder. Open them and press Ctrl+O to see the shape overlay (rendered with Batik). The information about the internal shapes and shading exists in the SVG files, but I'm not using it in any way.

i don't know too much about this, but what would make textured shapes etc be so hard to implement? from the looks of it most of the work is already done...

It can be done, quite easily actually, but there's a big difference between a texturing demo and a full-blown library that supports SVG rendering.
Offline bitshit

Junior Member




Java games rock!!


« Reply #20 - Posted 2006-09-14 15:27:18 »

ok, well I asked all those questions because im currently thinking about creating a framework in which shapes are fundamental;
for example it will contain a gui system which uses shapes as base for widgets, so it seems like a good idea to make these shapes as generic as possible (so I can use them for other purposes aswell), would it be a good idea to stick to the SVG specification for that? (maybe use or interface the batik library)

i'd like to have the implementation for rendering these shapes abstracted too (be it java2d, jogl, lwjgl etc), so maybe I could use zShape for rendering these shapes on hardware?
Offline Spasi
« Reply #21 - Posted 2006-09-18 00:46:31 »

I updated zShapes (~3.8MB) again. A font map file can now be created from the Tools menu. The whole unicode range can be used, even supplementary characters (>16-bit, surrogates are fully supported in the renderer). Select a font, choose all or some of the unicode ranges available and press OK to create the font map file.

Warning: Some fonts contain tens of thousands of glyphs and the triangulation process takes a lot of time (not optimized yet). Most fonts are ok though, for example, the Arial font with ~1150 glyphs takes 14 seconds to complete on my machine.

The Viewer has also been updated to support font maps. Press 'M' to select a font map, then select a text file and the proper encoding. Press 'I' for italics, 'U' for underlined and 'S' for strikethrough (see README or the built-in help for more shortcuts).

Two more improvements left (faster font map creation and better antialiasing quality) and then I'll release the source code.
Offline Spasi
« Reply #22 - Posted 2006-09-18 00:59:21 »

ok, well I asked all those questions because im currently thinking about creating a framework in which shapes are fundamental; for example it will contain a gui system which uses shapes as base for widgets

Yes, absolutely. A resolution independent GUI (not only text) is one of the things I want to try as an application of zShapes. Another one is projected texturing (as an example in our game, a team logo projected on a hoplite's shield).

so it seems like a good idea to make these shapes as generic as possible (so I can use them for other purposes aswell), would it be a good idea to stick to the SVG specification for that? (maybe use or interface the batik library)

i'd like to have the implementation for rendering these shapes abstracted too (be it java2d, jogl, lwjgl etc), so maybe I could use zShape for rendering these shapes on hardware?

Unless you implement the whole SVG spec, it would have to be a small subset of it. But yes, at least for simple stuff, I think it can be done.
Offline bitshit

Junior Member




Java games rock!!


« Reply #23 - Posted 2006-09-18 12:27:19 »

Quote
Yes, absolutely. A resolution independent GUI (not only text) is one of the things I want to try as an application of zShapes. Another one is projected texturing (as an example in our game, a team logo projected on a hoplite's shield).

That's great! I think I'll better wait a bit to see how things develop given my limited expirience and your & Ulfjacks effords in that area Wink
Offline Spasi
« Reply #24 - Posted 2006-10-08 15:38:16 »

Hi again,

This is the (probably) final release of zShapes in binary (4.12MB) and source (4.02MB) form. Some notes:

- Both archives contain the samples
- The BSD license is used for the source
- There's an ant script with the following targets:
    ant jars (creates the binaries)
    ant editor (runs the Editor)
    ant viewer (runs the Viewer)

I didn't have much time lately, so I couldn't make any further improvements to the antialiasing quality. I managed to improve the font map creation speed though (around 100 glyphs per second on my machine).
Offline sunsett

Senior Member




ribbit!


« Reply #25 - Posted 2010-05-30 17:12:51 »

I know this is a REALLY old thread, but I was hoping there might be some example source code somewhere on how to use this?
Offline Spasi
« Reply #26 - Posted 2010-05-30 17:33:33 »

The source archive contains a simple viewer (gr.zdimensions.zshapes.viewer package) with all the rendering code. The shaders are in there too.
Offline sunsett

Senior Member




ribbit!


« Reply #27 - Posted 2010-05-30 17:44:41 »

I created a 
Offline sunsett

Senior Member




ribbit!


« Reply #28 - Posted 2010-05-30 17:47:26 »

I created a font map and loaded it like:

1  
2  
fontMap = new FontMap(".../test.zfm");
font = new Font(fontMap, 32.0f);


Then to render it I used:

1  
font.render("Hello World!", false, 0.0f);


I get no errors but nothing is displaying on the screen...is there something else I need to do to make this function?
Offline Spasi
« Reply #29 - Posted 2010-05-30 18:16:56 »

Yes, the Font and FontMap classes only encapsulate the font geometry/information, they don't know how to render themselves. What you need is a ShapeRenderer implementation. Some example code:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
// Init
ContextCapabilities caps = GLContext.getCapabilities();
ShapeRenderer renderer = ShapeRenderer.shapeRendererGetHard(caps); // or .shapeRendererGetAA(caps) for antialiased shapes

FontMap fontMap = new FontMap(".../test.zfm");
Font font = new Font(fontMap, 32.0f);

TextArea renderable = new TextArea(font, "Hello World!");

// Render
glEnable(GL_BLEND);
glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);

renderer.render(renderable);


The ShapeRenderer factory methods will return an implementation appropriate for your GPU. There are GLSL implementations and also ATI_fragment_shader and NV_register_combiners implementations for older hardware. The TextArea class is a simple Font wrapper that simplifies its use, it doesn't do anything special. For more details see the initialize, loadMap and renderShape methods in the ShapeViewer class.

Anyway, when you get this working and are more familiar with it, I'd highly recommend you rewrite the whole thing. It's really old code of a quick'n'dirty implementation.
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Riven (20 views)
2014-07-29 18:09:19

Riven (13 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (31 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (42 views)
2014-07-24 01:59:36

Riven (42 views)
2014-07-23 21:16:32

Riven (28 views)
2014-07-23 21:07:15

Riven (29 views)
2014-07-23 20:56:16

ctomni231 (60 views)
2014-07-18 06:55:21
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!