[gameprogrammer] Re: Vector Graphics (seconded request)
- From: Bob Pendleton <bob@xxxxxxxxxxxxx>
- To: Gameprogrammer Mailing List <gameprogrammer@xxxxxxxxxxxxx>
- Date: Tue, 09 Nov 2004 12:10:42 -0600
On Tue, 2004-11-09 at 01:52, Jon Harrop wrote:
> Bob, your post is based upon a rather outdated notion of "vector graphics".
> While this term can be used to refer to pre-raster displays, it is now more
> commonly used to refer to rendering capabilities similar to those of Adobe
> Illustrator, Corel DRAW, Xara X and so on. I believe this is the
> functionality Florian desires.
>
> On Tue, 02 Nov 2004 10:17:41, Bob Pendleton wrote:
> > On Tue, 2004-11-02 at 09:13, Florian Hufsky wrote:
> > > I found some hardware accelerated vector graphics libraries:
> > > http://www.chem.pwf.cam.ac.uk/~jdh30/programming/opengl/smoke/
> > > http://svgl.sourceforge.net/
> >
> > OpenGL (cross platform) and DirectX (MS Windows only) are your two best
> > choices.
>
> OpenGL and DirectX are _much_ more low level than this. Consider the OpenGL
> calls which would be required to render this vector-graphic image, for
> example:
>
> http://www.w3.org/Graphics/SVG/webdraw01.png
>
> This is clearly non-trivial!
>
> Both Smoke and SVGL aim to render such vector graphics by converting the
> conventional vector-graphics primitives (gradient and radial fills; areas
> enclosed by implicit lines and curves; stroked contours etc.) into OpenGL
> primitives (filling commands and triangle meshes). The hardest part of this
> is the efficient tesselation of vector "areas" into triangle meshes.
>
> > Folks, there is nothing new or special about vector graphics.
>
> I beg to differ. Vector graphics is still a very active area of research.
>
> > We've been
> > doing it for 50, maybe 60 years. At the core of every 3D graphics
> > systems is a vector graphic system.
>
> Albeit a rather incapable system.
>
> As the author of Smoke, I can comment on what I have done which is new: Smoke
> can render vector graphics around two orders of magnitude more quickly than
> software-based renderers (such as those found in current Adobe and Corel
> software) partly by using hardware acceleration and partly through the
> careful selection of appropriate data structures and algorithms.
What you did was discover that the hardware designers had already put
all the functionality you needed into the hardware and you used it by
means of a library such as OpenGL or DirectX. I don't want to demean the
algorithmic and data structure work you did, I know how hard that is.
But, the fact still remains that the low level libraries and the
hardware already had all the functionality needed to do the job. Why do
you thing that is?
> This is a
> very difficult task and one which had never been addressed previously, to the
> best of my knowledge.
You really need to read some history. There are reasons why all the
functionality you needed was already there. It is because the need for
the functionality has been worked out over the last 50 years and
hardware and software were built to give it too you. Adding a higher
level interface to the functionality is a valid and useful activity, we
would all hate to have to work in machine language just as much as we
would have to write out individual OpenGL commands for every tiny
triangle in a complex image. But, in the end you are only exposing
functionality that was all ready there. You are taking advantage of the
new rendering hardware to convert geometry into pixels.
> The latest, closed-source version of Smoke is even more
> capable, being able to render hugely detailed vector graphics in real-time.
> This functionality is great for cartography, for example, and I believe it
> will underpin the next generation of GUIs.
Yep, isn't it nice that we can now count on having the hardware support
needed for things like that on inexpensive PCs?
>
> The SVGL crew were aiming more at SVG compliance (which I quickly gave up
> on!)
> and, consequently, SVGL is better suited to rendering SVG but, most notably,
> is not very suitable for real-time panning, zooming and animation. In
> particular, SVGL lacks the ability to retesselate adaptively and efficiently.
>
> Cheers,
> Jon.
Bob Pendleton
>
>
> ---------------------
> To unsubscribe go to http://gameprogrammer.com/mailinglist.html
>
--
+--------------------------------------+
+ Bob Pendleton: writer and programmer +
+ email: Bob@xxxxxxxxxxxxx +
+ blog: www.Stonewolf.net +
+ web: www.GameProgrammer.com +
+--------------------------------------+
---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html
- Follow-Ups:
- [gameprogrammer] Re: Vector Graphics (seconded request)
- From: Jon Harrop
- References:
- [gameprogrammer] Re: Vector Graphics (seconded request)
- From: Jon Harrop
Other related posts:
- » [gameprogrammer] Re: Vector Graphics (seconded request)
- » [gameprogrammer] Re: Vector Graphics (seconded request)
- » [gameprogrammer] Re: Vector Graphics (seconded request)
- » [gameprogrammer] Re: Vector Graphics (seconded request)
- » [gameprogrammer] Re: Vector Graphics (seconded request)
- » [gameprogrammer] Re: Vector Graphics (seconded request)
- » [gameprogrammer] Re: Vector Graphics (seconded request)
- » [gameprogrammer] Re: Vector Graphics (seconded request)
- » [gameprogrammer] Re: Vector Graphics (seconded request)
- [gameprogrammer] Re: Vector Graphics (seconded request)
- From: Jon Harrop
- [gameprogrammer] Re: Vector Graphics (seconded request)
- From: Jon Harrop