Well... The hard way is very gratifying. We could have worked on an integration of D3 in Pharo instead of working on Roassal :)
Alexandre Envoyé de mon iPhone > Le 31 déc. 2014 à 11:38, kilon alios <[email protected]> a écrit : > > 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 ? >
