I dont doubt for a minute it will be a difficult task , this is why I chose not to do it and instead I went down the easy route of relying on existing graphics engines in my case Blender which I try to expose it to Pharo. I learned the hard way how much time one can waste doing things the hard way.
On Tue, Dec 30, 2014 at 10:59 PM, Ronie Salgado <[email protected]> wrote: > Is this a real concern ? Afterall vector data is a lot less complex than >> 3d geometry and CPUs nowdays are multicore. > > For really smooth and complex animations, yes it is a concern. > Performance. If the objective is to draw a static shape or a slow > animation, it is not a big problem. Also CPU <-> GPU data transferring is > an expensive operation that has to be avoided if possible. > > Actually 2D vector data is more complex. 3D geometry comes already > processed to be directly rendered, and it is represented by only two > arrays: vertices and indices. > > In contrast, 2D vector data is represented by a stream of commands that > have to be evaluated. > > BTW, we don't have support for real multithreading in Pharo, and we will > not have it for a very long time. The closest thing to real multithreading > that we are getting in the near term > >> Don't know about the Opengl backend of Cairo. Igor also once shown me a >> Spec for vector graphics on OpenGL by Khronos Group. >> > Well, there is OpenVG designed for mobile platform(Android and iOS). > OpenVG is not supported by desktop graphic cards vendors. > > The closest thing we have in the desktop world is the NV_path_rendering > NVIDIA only extension. At least the paper that describes this extension is > really good. The bad thing is that it depends at least partially in the > Loop-Blinn algorithm that is patented, if I remember right. > > Newest OpenGL versions also come with dynamic tesselation geometry shaders >> that basically increase the detail of a 3d object the closer a camera gets >> to it which is similar to vector graphics which is something that could >> also work as basic via NBOpenGL to bring Athens to 3d side completely >> bypassing Cairo. >> > > In first place, not all of the world have at least DX11/OpenGL 4.xx level > graphic card. But, it does not matter too much because the hardware > tessellation does not help you anything with the main problem. > > The biggest problem is that 2D vector paths can be concave, and they can > have a hole . The easiest way to support it is by using the stencil buffer, > and in my opinion is the method with the better results. In fact, the > NV_path_rendering extension is implemented in this way, but directly in the > OpenGL driver. > > This method renders first the tessellated path with a triangle fan, with > the stencil test set to invert the stencil buffer bits. In this way, the > stencil buffer holds 1 in the points that are inside of the path, and 0 in > the points that are outside of the path. > > Then, the bounding box of the path is covered with fill color/gradient, > but with the stencil test set to only pass when the stencil buffer value is > 1, and to also clear the stencil buffer in the covered region during the > process to allow rendering more paths elements. > > Each one of the changes to the way the stencil buffer is used involves a > state change, which is expensive. I think this is the reason of why NVIDIA > implemented their extension directly in the OpenGL. > > I know of these problems because I implemented once the stencil method in > C++ with OpenGL. > > The old opengl Cairo backend worked by triangulating the paths. > Triangulation of concave geometry is hard to do, and there some degenerate > case in which it produces bad results. > > Best regards > Ronie > > 2014-12-30 16:58 GMT-03:00 kilon alios <[email protected]>: > > Is this a real concern ? Afterall vector data is a lot less complex than >> 3d geometry and CPUs nowdays are multicore. >> >> Don't know about the Opengl backend of Cairo. Igor also once shown me a >> Spec for vector graphics on OpenGL by Khronos Group. >> >> So there are alternatives but as always it will require someone doing the >> hard work to bring that functionality to Pharo. >> >> Newest OpenGL versions also come with dynamic tesselation geometry >> shaders that basically increase the detail of a 3d object the closer a >> camera gets to it which is similar to vector graphics which is something >> that could also work as basic via NBOpenGL to bring Athens to 3d side >> completely bypassing Cairo. >> >> On Tue, Dec 30, 2014 at 9:18 PM, Ronie Salgado <[email protected]> >> wrote: >> >>> Athens uses Cairo , Cairo can be used with OpenGL. You can use Cairo to >>>> apply a 2d vector graphic as a texture to a 3d polygon. Cairo website shows >>>> several examples of this. That means its possible to have 2d vector >>>> graphics in 3d space as if its true 3d. >>>> >>> I do not think that is going to work easily with the best performance >>> possible. Cairo could be using OpenGL, but probably in a different OpenGL >>> than the one that is being used for 3d graphics. >>> >>> In addition, the Cairo OpenGL backend is experimental ( >>> http://cairographics.org/OpenGL/) . Currently you have to render into a >>> surface in CPU, then transfer it into GPU and then render the polygon. A >>> naive version using the OpenGL backend is going to have GPU->CPU->GPU >>> roundtrip >>> >>> If we are using this route, I think that is better to just use the >>> current version of Athens for this. With Athens we can render into a Form, >>> which can be used to populate a Woden/Roassal texture or transferred >>> directly to OpenGL. This has the advantage of not having a explicit >>> dependency in Cairo. I guess that I will make a demo of this later. It >>> should be easy. >>> >>> I think that a longer term approach could be having a custom renderer, >>> tailored for Athens using OpenGL or maybe OpenCL. >>> >>> 2D vector graphics are really hard. In my opinion they are harder than >>> 3d graphics because of concave self intersecting paths. Stroking a path can >>> be really hard because of thins such as tapering. >>> >>> The 3D hardware is designed to draw efficiently points, lines and >>> triangles. All of them are simple convex polygon. Most of the 2D vector >>> engines such as Cairo are software renderer, scanliners to be more >>> specific. The old cairo opengl backend had to tessellate the paths >>> >>> Later I am going to take a better look in Jun. And see how I can >>> integrate with Woden/Woden-Roassal. For what I have seen in the videos, it >>> seems to be using software rendering. Currently I have been working in my >>> internship about volumetric data visualization and the new FFI. >>> >>> 2014-12-30 11:01 GMT-03:00 kilon alios <[email protected]>: >>> >>> Athens uses Cairo , Cairo can be used with OpenGL. You can use Cairo to >>>> apply a 2d vector graphic as a texture to a 3d polygon. Cairo website shows >>>> several examples of this. That means its possible to have 2d vector >>>> graphics in 3d space as if its true 3d. >>>> >>>> On Tue, Dec 30, 2014 at 12:10 AM, stepharo <[email protected]> wrote: >>>> >>>>> Sven >>>>> >>>>> Jun is a 3D frameworks developed in 1998 in VisualWorks >>>>> http://aokilab.kyoto-su.ac.jp/jun/index.html >>>>> It was quite advanced and this is nice to get more people doing 3d in >>>>> Pharo. >>>>> They are using the back -end developed by ronie and JB and this is cool >>>>> >>>>> Athens is just a canvas and a oo decomposition of the canvas, brush >>>>> and strokes >>>>> nothing related to 3D. >>>>> Stef >>>>> >>>>> >>>>> Le 29/12/14 20:20, Sven Van Caekenberghe a écrit : >>>>> >>>>> On 29 Dec 2014, at 15:36, stepharo <[email protected]> wrote: >>>>>>> >>>>>>> https://www.youtube.com/watch?v=sH_P5otiWJM&feature=youtu.be >>>>>>> >>>>>> It certainly looks nice, but what is Jun exactly ? >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >
