Does the script Ronie sent work for you Volkert? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> On Dec 1, 2015, at 1:11 AM, Volkert <volk...@komponentenwerkstatt.de> wrote: > > That is cool. Thank you ... > > BW, > Volkert > > On 01.12.2015 01:25, Ronie Salgado wrote: >> Hello, >> >> I added a fallback method for the selection, so the missing extension should >> not be required. The following script should work in a playground. >> >> =========================================================== >> >> view := RWView new. >> elements := RWCube elementsOn: (1 to: 50). >> RWCubeLayout on: elements. >> elements do: [:el | >> el when: RWMouseButtonDown do: [ :ev | >> ev element color: WDColor red. >> ev element changed. >> ] >> ]. >> >> view addAll: elements. >> view addInteraction: RWMouseKeyControl. >> view open >> >> ============================================================ >> I tested it on: >> >> glxinfo >> OpenGL vendor string: Intel Open Source Technology Center >> OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile >> >> cat /proc/cpuinfo >> model name : Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz >> >> Best regards, >> Ronie >> >> 2015-11-29 3:33 GMT-03:00 Ben Coman <b...@openinworld.com >> <mailto:b...@openinworld.com>>: >> Interesting stuff Ronie. Hopefully we'll gain a lot in portability with >> Vulkan. What I find interesting is the use of Standard Portable >> Intermediate Representation (SPIR) common to Vulkan graphics API and OpenCL >> compute API. [1] is an interesting article outlining this. [2] indicates a >> few programming languages will compile direct to SPIR and I wonder if Pharo >> might be able to do the same? New technologies (SPIR) => new opportunities >> to draw the curious to Pharo. Wild speculation... be able to debug a shader >> on a SPIR simulator running inside Pharo. >> >> (btw, apparently SPIR is pronounced "spear" not to be confused with our >> "spur" vm) >> >> [2] p39,40 says "Debug information via standardized API calls" and "Khronos >> encouraging open community of tools e.g. shader debugging" >> which may provide an opportunity to produce a shader debugging tool for use >> by individual developers in a corporate environment that constrains their >> language choice for the main application, but have more flexibility to >> choice their tools. So potentially once exposed to Pharo we hook some of >> them. Maybe interesting debugging info could be gathered that could be >> presented by Roassal. >> >> [3] p4 says "SPIR-V is fully set up to support multiple source languages" >> and "SPIR-V also enables development of new experimental languages" and [4] >> says "Enable third-party code generation targeting OpenCL platforms without >> going through OpenCL C." So maybe(?) this makes it easier to get fast >> computing within Pharo using more of our own tools? >> >> [1] >> http://www.pcper.com/reviews/General-Tech/GDC-15-What-Vulkan-glNext-SPIR-V-and-OpenCL-21 >> >> <http://www.pcper.com/reviews/General-Tech/GDC-15-What-Vulkan-glNext-SPIR-V-and-OpenCL-21> >> [2] >> https://www.khronos.org/assets/uploads/developers/library/2015-sigasia/SIGGRAPH-Asia_Nov15.pdf >> >> <https://www.khronos.org/assets/uploads/developers/library/2015-sigasia/SIGGRAPH-Asia_Nov15.pdf> >> [3] https://www.khronos.org/registry/spir-v/papers/WhitePaper.pdf >> <https://www.khronos.org/registry/spir-v/papers/WhitePaper.pdf> >> [4] https://www.khronos.org/faq/spir <https://www.khronos.org/faq/spir> >> >> cheers -ben >> >> On Sun, Nov 29, 2015 at 6:13 AM, Ronie Salgado <ronies...@gmail.com >> <mailto:ronies...@gmail.com>> wrote: >> Hi Stef, >> >> I think that this is important that people can pick different ("compatible") >> driver/framework back-end. >> You see if Woden is only built to work on something that does not run on mac >> or windows then >> it will be limited. >> The problem is not Window or Mac. The problem is Linux. >> >> We are having some discussion on this with Alex on this. I am going to try >> to remove the requirement on that extension by providing a fallback method >> for the selection, that does not require that extension. Then I will test it >> in my laptop by selecting the Intel driver (My laptop has the integrated >> Intel card in the CPU and a dedicated AMD graphics cards). >> >> However Woden-Roassal relies a lot on hardware instancing support to be able >> to draw a lot of dynamic cubes. The alternative is to use a vertex buffer >> and index buffer that holds all of the transformed visible geometry that is >> updated on each frame in the worst case scenario. In >> the best case scenario (static cubes or objects), they are >> updated only once. This relies a lot on the CPU because all of the >> transformations has to be done manually on the CPU. >> >> This is not a hardware problem, this is a drivers problem because OpenGL is >> huge, complex, unefficient, does not represent the graphics hardware. The >> Mesa Open Source guys are not able to keep pace with the extension hell >> known as OpenGL. In Ubuntu 14.04 Mesa supports up until OpenGL 3.0 >> compatibility profile, and OpenGL 3.1 core profile. The current version of >> OpenGL is 4.5. Each version of OpenGL has a different version of GLSL >> (OpenGL Shader Language), which makes harder to stick with one reasonable >> subset and then support features depending on which hardware you are >> running. In contrast, if you are developing for Direct3D in Windows, you >> only need to choose between Direct3D 9(Windows XP), 11(Vista I think/7/8), >> 12(Windows 10) and thats it. In Direct3D you do not have to deal with >> hardware vendor extensions because there are not extensions. >> >> By using instancing, I have a buffer with the geometry of a single cube or >> shape. Then I have another buffer with the transformation and color of each >> cube or simple shape. When updating the position, size or color of an >> element I only have to change a single entry in this buffer. >> >> The original Roassal 3D used a draw call per element. This more flexible, >> but a lot slower. 20.000 cubes in Roassal3D vs 300.000-600.000 in >> Woden-Roassal visibles at the same time. The overhead of a draw call is >> produced because some validations are made by the OpenGL driver for each >> draw call. >> >> A draw call per-element is only reasonable when using Direct3D 12(Window), >> Metal(iOS, OS X) or Vulkan (Linux, Windows and mobiles) because there are >> designed to remove the overhead of draw calls. This is the approach that I >> am going to use in Woden 2 via an abstraction layer that I am making in >> C/C++ above the graphics API. Currently I have a backend for Direct3D 12 and >> OpenGL 4.x (it should be possible to use OpenGL 3.3, but I need to test it). >> I made the OpenGL backend because Vulkan has not been released yet. It is >> impossible to get the best performance by using the OpenGL backend because >> of its design. In theory it should be possible to make a backend for OpenGL >> 2.0 and OpenGL 2.0 ES, but it will be really hard to do. And it will not >> have a good performance. >> >> Greetings, >> Ronie >> >> >> 2015-11-28 14:41 GMT-03:00 stepharo < >> <mailto:steph...@free.fr>steph...@free.fr <mailto:steph...@free.fr>>: >> Ronie >> >> I think that this is important that people can pick different ("compatible") >> driver/framework back-end. >> You see if Woden is only built to work on something that does not run on mac >> or windows then >> it will be limited. >> >> Stef >> >> Le 25/11/15 00:14, Ronie Salgado a écrit : >>> >>> What do you mean with "modern"? >>> By modern I mean a graphics card a with graphics driver that supports at >>> least OpenGL 4.x. That Intel HD graphics card is capable of supporting at >>> least OpenGL 4.2, but the Open Source Mesa driver gives you support up >>> until OpenGL 3.1. Unfortunately, unlike with AMD or NVIDIA graphics cards, >>> the open source driver is the official driver. >>> >>> Woden-Roassal requires integer arithmetic in shaders which is used to >>> support the selection of objects. Integer arithmetics in shaders requires >>> at least OpenGL 3.3, or the missing extension for which you are receiving >>> the error. >>> >>> It is not required by the Woden-Core api, so you should be able to try the >>> following in a workspace: >>> >>> WDFPSSimpleExample6 new open >>> >>> My notebook with an HD Graphics 4400 has no problems with all "three.js" >>> demos found here <http://threejs.org/>http://threejs.org/ >>> <http://threejs.org/>. >>> Three.js or any WebGL based example is a bad test for that graphics card. >>> WebGL is based in OpenGL ES 2.0 which is a subset of OpenGL 2.0. This is a >>> very old technology for that graphics card. >>> >>> Woden will be using Vulkan in the future. According to this Phoronix >>> article ( >>> <http://www.phoronix.com/scan.php?page=news_item&px=LunarG-Vulkan-AMA>http://www.phoronix.com/scan.php?page=news_item&px=LunarG-Vulkan-AMA >>> <http://www.phoronix.com/scan.php?page=news_item&px=LunarG-Vulkan-AMA>), >>> Valve has already made a proper Vulkan driver for the Intel graphics cards. >>> We only need an official release of the Vulkan spec. >>> >>> Best regards >>> Ronie >>> >>> 2015-11-24 18:50 GMT-03:00 Volkert < >>> <mailto:volk...@komponentenwerkstatt.de>volk...@komponentenwerkstatt.de >>> <mailto:volk...@komponentenwerkstatt.de>>: >>> My notebook with an HD Graphics 4400 has no problems with all "three.js" >>> demos found here <http://threejs.org/>http://threejs.org/ >>> <http://threejs.org/>. >>> >>> What do you mean with "modern"? >>> >>> <Mail Attachment.png> >>> >>> >>> On 24.11.2015 22:25, Ronie Salgado wrote: >>>> You need a modern graphics card. Open source graphics drivers are not >>>> supported because there are very behind in their implementations of OpenGL. >>>> >>>> >>>> 2015-11-24 17:28 GMT-03:00 Volkert < >>>> <mailto:volk...@komponentenwerkstatt.de>volk...@komponentenwerkstatt.de >>>> <mailto:volk...@komponentenwerkstatt.de>>: >>>> But not on my linux box .... ubuntu 14.04 :-( >>>> >>>> <Mail Attachment.png> >>>> >>>> >>>> >>>> On 24.11.2015 21:03, Alexandre Bergel wrote: >>>>> Woden works in Pharo 5.0 >>>>> I have just tried. >>>>> >>>>> Alexandre >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel <http://www.bergel.eu/>http://www.bergel.eu >>>>> <http://www.bergel.eu/> >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>>> On Nov 24, 2015, at 3:15 PM, Volkert < >>>>>> <mailto:volk...@komponentenwerkstatt.de>volk...@komponentenwerkstatt.de >>>>>> <mailto:volk...@komponentenwerkstatt.de>> wrote: >>>>>> >>>>>> Cool ... >>>>>> >>>>>> Which Pharo Version? I tried Pharo 4.0 and got this error: >>>>>> >>>>>> <edcefcdd.png> >>>>>> >>>>>> >>>>>> On 24.11.2015 12:50, Alexandre Bergel wrote: >>>>>>>> Do we have a tutorial? i found only >>>>>>>> <http://woden.ronie.cl/>http://woden.ronie.cl <http://woden.ronie.cl/>. >>>>>>>> >>>>>>>> What about mouse control and object selection. It that possible? >>>>>>> >>>>>>> Yes. >>>>>>> >>>>>>> To load Woden: >>>>>>> >>>>>>> Gofer new smalltalkhubUser: 'ronsaldo' project: 'Woden'; package: >>>>>>> 'ConfigurationOfWoden'; load. (Smalltalk at: #ConfigurationOfWoden) >>>>>>> loadBleedingEdge. >>>>>>> >>>>>>> Try: >>>>>>> =-=-=-==-=-=-==-=-=-==-=-=-= >>>>>>> v := RWView new. >>>>>>> >>>>>>> 1 to: 100 do: [ :i | >>>>>>> e := RWCube element. >>>>>>> e when: RWMouseButtonDown do: [ :ev | >>>>>>> ev element shape color: WDColor green. >>>>>>> ev element changed. >>>>>>> ]. >>>>>>> v add: e. >>>>>>> ]. >>>>>>> RWXZGridLayout on: v elements. >>>>>>> v addInteraction: RWMouseKeyControl. >>>>>>> v camera position: (WDVector3 x: 0.0 y: 0.0 z: 3.0). >>>>>>> v open >>>>>>> =-=-=-==-=-=-==-=-=-==-=-=-= >>>>>>> Use the keys A S D W and the moose to navigate. Click on cube to make >>>>>>> them green >>>>>>> >>>>>>> <Mail Attachment.png> >>>>>>> >>>>>>> Cheers, >>>>>>> Alexandre >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> BW, >>>>>>>> Volkert >>>>>>>> >>>>>>>> On 22.11.2015 21:10, Alexandre Bergel wrote: >>>>>>>>> We have also put quite some effort on Woden, a 3d engine for Pharo… >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Alexandre >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Nov 22, 2015, at 2:56 PM, Dimitris Chloupis < >>>>>>>>>> <mailto:kilon.al...@gmail.com>kilon.al...@gmail.com >>>>>>>>>> <mailto:kilon.al...@gmail.com>> wrote: >>>>>>>>>> >>>>>>>>>> its possible via my Ephestos project, to render to video or real >>>>>>>>>> time but the project is still very much a WIP. Its doable but >>>>>>>>>> require some python knowledge and knowledge of Blender UI and API. I >>>>>>>>>> will be making a true Pharo API for it fairly soon but as you can >>>>>>>>>> imagine these things take time. >>>>>>>>>> >>>>>>>>>> On Sun, Nov 22, 2015 at 6:35 PM Volkert < >>>>>>>>>> <mailto:volk...@komponentenwerkstatt.de>volk...@komponentenwerkstatt.de >>>>>>>>>> <mailto:volk...@komponentenwerkstatt.de>> wrote: >>>>>>>>>> Is this possible with Pharo? >>>>>>>>>> >>>>>>>>>> <http://www.asterank.com/3d/>http://www.asterank.com/3d/ >>>>>>>>>> <http://www.asterank.com/3d/> >>>>>>>>>> >>>>>>>>>> BW, >>>>>>>>>> Volkert >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >> >> >> >> >
