Pharo for Data Visualization
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 <volkert@komponentenwerkstatt.de> wrote:
Is this possible with Pharo?
BW, Volkert
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 <kilon.alios@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 <volkert@komponentenwerkstatt.de> wrote: Is this possible with Pharo?
BW, Volkert
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I have seen this ... looks promising. Do we have a tutorial? i found only http://woden.ronie.cl. What about mouse control and object selection. It that possible? 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 <kilon.alios@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 <volkert@komponentenwerkstatt.de> wrote: Is this possible with Pharo?
BW, Volkert
Do we have a tutorial? i found only 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 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 <kilon.alios@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 <volkert@komponentenwerkstatt.de> wrote: Is this possible with Pharo?
BW, Volkert
Cool ... Which Pharo Version? I tried Pharo 4.0 and got this error: On 24.11.2015 12:50, Alexandre Bergel wrote:
Do we have a tutorial? i found only 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
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 <kilon.alios@gmail.com <mailto:kilon.alios@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 <volkert@komponentenwerkstatt.de <mailto:volkert@komponentenwerkstatt.de>> wrote: Is this possible with Pharo?
BW, Volkert
I tried in the last version of Moose (6.0) Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Nov 24, 2015, at 3:15 PM, Volkert <volkert@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.alios@gmail.com>kilon.alios@gmail.com <mailto:kilon.alios@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:volkert@komponentenwerkstatt.de>volkert@komponentenwerkstatt.de <mailto:volkert@komponentenwerkstatt.de>> wrote: Is this possible with Pharo?
http://www.asterank.com/3d/ <http://www.asterank.com/3d/>
BW, Volkert
On 24 Nov 2015, at 16:13, Alexandre Bergel <alexandre.bergel@me.com> wrote:
I tried in the last version of Moose (6.0)
Keep in mind that requiring Moose when people do not want to do software analysis is not good. I would never even think about starting with Moose. I do not even want to. If you tell me âload Xâ, it needs to work in Pharo.
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Nov 24, 2015, at 3:15 PM, Volkert <volkert@komponentenwerkstatt.de <mailto:volkert@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.alios@gmail.com>kilon.alios@gmail.com <mailto:kilon.alios@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:volkert@komponentenwerkstatt.de>volkert@komponentenwerkstatt.de <mailto:volkert@komponentenwerkstatt.de>> wrote: Is this possible with Pharo?
http://www.asterank.com/3d/ <http://www.asterank.com/3d/>
BW, Volkert
Hi, On 24/11/15 14:16, Marcus Denker wrote:
On 24 Nov 2015, at 16:13, Alexandre Bergel <alexandre.bergel@me.com <mailto:alexandre.bergel@me.com>> wrote:
I tried in the last version of Moose (6.0)
Keep in mind that requiring Moose when people do not want to do software analysis is not good.
I would never even think about starting with Moose. I do not even want to. If you tell me âload Xâ, it needs to work in Pharo.
Just for curiosity, what is the Moose's feature that makes development of Roassal happen there and not on plain Pharo 4? Is it because moose is integrated with package that Roassal needs? Cheers, Offray
Well. You need GT to get the best experience with Roassal. Alexandre
Le 24 nov. 2015 à 17:00, Offray Vladimir Luna Cárdenas <offray@riseup.net> a écrit :
Hi,
On 24/11/15 14:16, Marcus Denker wrote:
On 24 Nov 2015, at 16:13, Alexandre Bergel <alexandre.bergel@me.com> wrote:
I tried in the last version of Moose (6.0)
Keep in mind that requiring Moose when people do not want to do software analysis is not good.
I would never even think about starting with Moose. I do not even want to. If you tell me âload Xâ, it needs to work in Pharo.
Just for curiosity, what is the Moose's feature that makes development of Roassal happen there and not on plain Pharo 4? Is it because moose is integrated with package that Roassal needs?
Cheers,
Offray
On 24 Nov 2015, at 17:43, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Well. You need GT to get the best experience with Roassal.
And it is in Pharo? No?
Alexandre
Le 24 nov. 2015 à 17:00, Offray Vladimir Luna Cárdenas <offray@riseup.net <mailto:offray@riseup.net>> a écrit :
Hi,
On 24/11/15 14:16, Marcus Denker wrote:
On 24 Nov 2015, at 16:13, Alexandre Bergel < <mailto:alexandre.bergel@me.com>alexandre.bergel@me.com <mailto:alexandre.bergel@me.com>> wrote:
I tried in the last version of Moose (6.0)
Keep in mind that requiring Moose when people do not want to do software analysis is not good.
I would never even think about starting with Moose. I do not even want to. If you tell me âload Xâ, it needs to work in Pharo.
Just for curiosity, what is the Moose's feature that makes development of Roassal happen there and not on plain Pharo 4? Is it because moose is integrated with package that Roassal needs?
Cheers,
Offray
Hi, Roassal2 is developed on top of Pharo 5. There is a job that tests the development version of ConfigurationOfRoassal2 on top of the latest Pharo 5.0: https://ci.inria.fr/moose/job/roassal2/ Often, people use the Moose image because it has several other things loaded that are convenient, but that is it. Other than that it should be Pharo 5. Cheers, Doru
On Nov 24, 2015, at 9:48 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 24 Nov 2015, at 17:43, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Well. You need GT to get the best experience with Roassal.
And it is in Pharo? No?
Alexandre
Le 24 nov. 2015 à 17:00, Offray Vladimir Luna Cárdenas <offray@riseup.net> a écrit :
Hi,
On 24/11/15 14:16, Marcus Denker wrote:
On 24 Nov 2015, at 16:13, Alexandre Bergel <alexandre.bergel@me.com> wrote:
I tried in the last version of Moose (6.0)
Keep in mind that requiring Moose when people do not want to do software analysis is not good.
I would never even think about starting with Moose. I do not even want to. If you tell me âload Xâ, it needs to work in Pharo.
Just for curiosity, what is the Moose's feature that makes development of Roassal happen there and not on plain Pharo 4? Is it because moose is integrated with package that Roassal needs?
Cheers,
Offray
-- www.tudorgirba.com "Every thing should have the right to be different."
Woden works in Pharo 5.0 I have just tried. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Nov 24, 2015, at 3:15 PM, Volkert <volkert@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.alios@gmail.com>kilon.alios@gmail.com <mailto:kilon.alios@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:volkert@komponentenwerkstatt.de>volkert@komponentenwerkstatt.de <mailto:volkert@komponentenwerkstatt.de>> wrote: Is this possible with Pharo?
http://www.asterank.com/3d/ <http://www.asterank.com/3d/>
BW, Volkert
But not on my linux box .... ubuntu 14.04 :-( 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Nov 24, 2015, at 3:15 PM, Volkert <volkert@komponentenwerkstatt.de <mailto:volkert@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.
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 <kilon.alios@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 <volkert@komponentenwerkstatt.de> wrote: Is this possible with Pharo?
BW, Volkert
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 <volkert@komponentenwerkstatt.de>:
But not on my linux box .... ubuntu 14.04 :-(
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Nov 24, 2015, at 3:15 PM, Volkert < <volkert@komponentenwerkstatt.de> volkert@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.
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 < <kilon.alios@gmail.com> kilon.alios@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 <volkert@komponentenwerkstatt.de> wrote: Is this possible with Pharo?
BW, Volkert
My notebook with an HD Graphics 4400 has no problems with all "three.js" demos found here http://threejs.org/. What do you mean with "modern"? 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 <volkert@komponentenwerkstatt.de <mailto:volkert@komponentenwerkstatt.de>>:
But not on my linux box .... ubuntu 14.04 :-(
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Nov 24, 2015, at 3:15 PM, Volkert <volkert@komponentenwerkstatt.de <mailto:volkert@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/>.
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 <kilon.alios@gmail.com <mailto:kilon.alios@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 <volkert@komponentenwerkstatt.de <mailto:volkert@komponentenwerkstatt.de>> wrote: Is this possible with Pharo?
BW, Volkert
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/.
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), 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 <volkert@komponentenwerkstatt.de>:
My notebook with an HD Graphics 4400 has no problems with all "three.js" demos found here http://threejs.org/.
What do you mean with "modern"?
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 <volkert@komponentenwerkstatt.de>:
But not on my linux box .... ubuntu 14.04 :-(
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Nov 24, 2015, at 3:15 PM, Volkert < <volkert@komponentenwerkstatt.de> volkert@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.
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 < <kilon.alios@gmail.com> kilon.alios@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 < <volkert@komponentenwerkstatt.de>volkert@komponentenwerkstatt.de> wrote: Is this possible with Pharo?
BW, Volkert
On 25.11.2015 00:14, Ronie Salgado wrote:
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.
Thanks for your clarification. So i have to wait for better drivers ...
It is not required by the Woden-Core api, so you should be able to try the following in a workspace:
WDFPSSimpleExample6 new open This is ok ...
My notebook with an HD Graphics 4400 has no problems with all "three.js" demos found here 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.
But it works for me ...
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), 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 <volkert@komponentenwerkstatt.de <mailto:volkert@komponentenwerkstatt.de>>:
My notebook with an HD Graphics 4400 has no problems with all "three.js" demos found here http://threejs.org/.
What do you mean with "modern"?
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 <volkert@komponentenwerkstatt.de <mailto:volkert@komponentenwerkstatt.de>>:
But not on my linux box .... ubuntu 14.04 :-(
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Nov 24, 2015, at 3:15 PM, Volkert <volkert@komponentenwerkstatt.de <mailto:volkert@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.
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 <kilon.alios@gmail.com <mailto:kilon.alios@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 <volkert@komponentenwerkstatt.de <mailto:volkert@komponentenwerkstatt.de>> wrote: Is this possible with Pharo?
BW, Volkert
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/.
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), 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 <volkert@komponentenwerkstatt.de <mailto:volkert@komponentenwerkstatt.de>>:
My notebook with an HD Graphics 4400 has no problems with all "three.js" demos found here http://threejs.org/.
What do you mean with "modern"?
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 <volkert@komponentenwerkstatt.de <mailto:volkert@komponentenwerkstatt.de>>:
But not on my linux box .... ubuntu 14.04 :-(
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Nov 24, 2015, at 3:15 PM, Volkert <volkert@komponentenwerkstatt.de <mailto:volkert@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.
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 <kilon.alios@gmail.com <mailto:kilon.alios@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 <volkert@komponentenwerkstatt.de <mailto:volkert@komponentenwerkstatt.de>> wrote: Is this possible with Pharo?
BW, Volkert
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 <stepharo@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/.
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), 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 <volkert@komponentenwerkstatt.de>:
My notebook with an HD Graphics 4400 has no problems with all "three.js" demos found here http://threejs.org/.
What do you mean with "modern"?
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 < <volkert@komponentenwerkstatt.de> volkert@komponentenwerkstatt.de>:
But not on my linux box .... ubuntu 14.04 :-(
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Nov 24, 2015, at 3:15 PM, Volkert < <volkert@komponentenwerkstatt.de> volkert@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.
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 < <kilon.alios@gmail.com> kilon.alios@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 < <volkert@komponentenwerkstatt.de>volkert@komponentenwerkstatt.de> wrote: Is this possible with Pharo?
<http://www.asterank.com/3d/>http://www.asterank.com/3d/
BW, Volkert
Here is what Ubuntu 14.04 running under VMWare 10 on Windows 8.1 gives (using 3D hardware acceleration): philippeback@ubuntu:~$ /usr/lib/nux/unity_support_test -p OpenGL vendor string: VMware, Inc. OpenGL renderer string: Gallium 0.4 on SVGA3D; build: RELEASE; OpenGL version string: 2.1 Mesa 10.3.2 Not software rendered: yes Not blacklisted: yes GLX fbconfig: yes GLX texture from pixmap: yes GL npot or rect textures: yes GL vertex program: yes GL fragment program: yes GL vertex buffer object: yes GL framebuffer object: yes GL version is 1.4+: yes Unity 3D supported: yes Phl On Sat, Nov 28, 2015 at 11:13 PM, Ronie Salgado <roniesalg@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 <stepharo@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/.
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), 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 <volkert@komponentenwerkstatt.de>:
My notebook with an HD Graphics 4400 has no problems with all "three.js" demos found here http://threejs.org/.
What do you mean with "modern"?
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 < <volkert@komponentenwerkstatt.de> volkert@komponentenwerkstatt.de>:
But not on my linux box .... ubuntu 14.04 :-(
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Nov 24, 2015, at 3:15 PM, Volkert < <volkert@komponentenwerkstatt.de>volkert@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.
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 < <kilon.alios@gmail.com>kilon.alios@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 < <volkert@komponentenwerkstatt.de>volkert@komponentenwerkstatt.de> wrote: Is this possible with Pharo?
<http://www.asterank.com/3d/>http://www.asterank.com/3d/
BW, Volkert
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-a... [2] https://www.khronos.org/assets/uploads/developers/library/2015-sigasia/SIGGR... [3] https://www.khronos.org/registry/spir-v/papers/WhitePaper.pdf [4] https://www.khronos.org/faq/spir cheers -ben On Sun, Nov 29, 2015 at 6:13 AM, Ronie Salgado <roniesalg@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 <stepharo@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/.
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), 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 <volkert@komponentenwerkstatt.de>:
My notebook with an HD Graphics 4400 has no problems with all "three.js" demos found here http://threejs.org/.
What do you mean with "modern"?
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 < <volkert@komponentenwerkstatt.de> volkert@komponentenwerkstatt.de>:
But not on my linux box .... ubuntu 14.04 :-(
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Nov 24, 2015, at 3:15 PM, Volkert < <volkert@komponentenwerkstatt.de>volkert@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.
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 < <kilon.alios@gmail.com>kilon.alios@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 < <volkert@komponentenwerkstatt.de>volkert@komponentenwerkstatt.de> wrote: Is this possible with Pharo?
<http://www.asterank.com/3d/>http://www.asterank.com/3d/
BW, Volkert
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 <btc@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-a... [2] https://www.khronos.org/assets/uploads/developers/library/2015-sigasia/SIGGR... [3] https://www.khronos.org/registry/spir-v/papers/WhitePaper.pdf [4] https://www.khronos.org/faq/spir
cheers -ben
On Sun, Nov 29, 2015 at 6:13 AM, Ronie Salgado <roniesalg@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 <stepharo@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/.
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), 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 <volkert@komponentenwerkstatt.de>:
My notebook with an HD Graphics 4400 has no problems with all "three.js" demos found here http://threejs.org/.
What do you mean with "modern"?
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 < <volkert@komponentenwerkstatt.de> volkert@komponentenwerkstatt.de>:
But not on my linux box .... ubuntu 14.04 :-(
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Nov 24, 2015, at 3:15 PM, Volkert < <volkert@komponentenwerkstatt.de>volkert@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.
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 < <kilon.alios@gmail.com>kilon.alios@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 < <volkert@komponentenwerkstatt.de>volkert@komponentenwerkstatt.de> wrote: Is this possible with Pharo?
<http://www.asterank.com/3d/>http://www.asterank.com/3d/
BW, Volkert
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 <btc@openinworld.com <mailto:btc@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-a... [2] https://www.khronos.org/assets/uploads/developers/library/2015-sigasia/SIGGR... [3] https://www.khronos.org/registry/spir-v/papers/WhitePaper.pdf [4] https://www.khronos.org/faq/spir
cheers -ben
On Sun, Nov 29, 2015 at 6:13 AM, Ronie Salgado <roniesalg@gmail.com <mailto:roniesalg@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 <stepharo@free.fr <mailto:stepharo@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/.
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), 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 <volkert@komponentenwerkstatt.de <mailto:volkert@komponentenwerkstatt.de>>:
My notebook with an HD Graphics 4400 has no problems with all "three.js" demos found here http://threejs.org/.
What do you mean with "modern"?
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 <volkert@komponentenwerkstatt.de <mailto:volkert@komponentenwerkstatt.de>>:
But not on my linux box .... ubuntu 14.04 :-(
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Nov 24, 2015, at 3:15 PM, Volkert <volkert@komponentenwerkstatt.de <mailto:volkert@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.
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 <kilon.alios@gmail.com <mailto:kilon.alios@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 <volkert@komponentenwerkstatt.de <mailto:volkert@komponentenwerkstatt.de>> wrote: Is this possible with Pharo?
BW, Volkert
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 <volkert@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 <btc@openinworld.com <mailto:btc@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-a... <http://www.pcper.com/reviews/General-Tech/GDC-15-What-Vulkan-glNext-SPIR-V-a...> [2] https://www.khronos.org/assets/uploads/developers/library/2015-sigasia/SIGGR... <https://www.khronos.org/assets/uploads/developers/library/2015-sigasia/SIGGR...> [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 <roniesalg@gmail.com <mailto:roniesalg@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:stepharo@free.fr>stepharo@free.fr <mailto:stepharo@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:volkert@komponentenwerkstatt.de>volkert@komponentenwerkstatt.de <mailto:volkert@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:volkert@komponentenwerkstatt.de>volkert@komponentenwerkstatt.de <mailto:volkert@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:volkert@komponentenwerkstatt.de>volkert@komponentenwerkstatt.de <mailto:volkert@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.alios@gmail.com>kilon.alios@gmail.com <mailto:kilon.alios@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:volkert@komponentenwerkstatt.de>volkert@komponentenwerkstatt.de <mailto:volkert@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
Yes. I tried it and it works on my linux system ... :-) On 01.12.2015 16:22, Alexandre Bergel wrote:
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 <volkert@komponentenwerkstatt.de <mailto:volkert@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 <btc@openinworld.com <mailto:btc@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-a... [2] https://www.khronos.org/assets/uploads/developers/library/2015-sigasia/SIGGR... [3] https://www.khronos.org/registry/spir-v/papers/WhitePaper.pdf [4] https://www.khronos.org/faq/spir
cheers -ben
On Sun, Nov 29, 2015 at 6:13 AM, Ronie Salgado <roniesalg@gmail.com <mailto:roniesalg@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 <stepharo@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/.
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), 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 <volkert@komponentenwerkstatt.de>:
My notebook with an HD Graphics 4400 has no problems with all "three.js" demos found here 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 <volkert@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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Nov 24, 2015, at 3:15 PM, Volkert <volkert@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.
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 <kilon.alios@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 <volkert@komponentenwerkstatt.de> wrote: Is this possible with Pharo?
BW, Volkert
Cool! -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Dec 1, 2015, at 1:56 PM, Volkert <volkert@komponentenwerkstatt.de> wrote:
Yes. I tried it and it works on my linux system ... :-)
On 01.12.2015 16:22, Alexandre Bergel wrote:
Does the script Ronie sent work for you Volkert?
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Dec 1, 2015, at 1:11 AM, Volkert < <mailto:volkert@komponentenwerkstatt.de>volkert@komponentenwerkstatt.de <mailto:volkert@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 < <mailto:btc@openinworld.com>btc@openinworld.com <mailto:btc@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 <http://www.pcper.com/reviews/General-Tech/GDC-15-What-Vulkan-glNext-SPIR-V-a...> [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 <https://www.khronos.org/assets/uploads/developers/library/2015-sigasia/SIGGR...> [3] <https://www.khronos.org/registry/spir-v/papers/WhitePaper.pdf>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 <https://www.khronos.org/faq/spir>
cheers -ben
On Sun, Nov 29, 2015 at 6:13 AM, Ronie Salgado < <mailto:roniesalg@gmail.com>roniesalg@gmail.com <mailto:roniesalg@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:stepharo@free.fr>stepharo@free.fr <mailto:stepharo@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:volkert@komponentenwerkstatt.de>volkert@komponentenwerkstatt.de <mailto:volkert@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:volkert@komponentenwerkstatt.de>volkert@komponentenwerkstatt.de <mailto:volkert@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:volkert@komponentenwerkstatt.de>volkert@komponentenwerkstatt.de <mailto:volkert@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.alios@gmail.com>kilon.alios@gmail.com <mailto:kilon.alios@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:volkert@komponentenwerkstatt.de>volkert@komponentenwerkstatt.de <mailto:volkert@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
On 01-12-15 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.
Works for me on Ubuntu 15.04 on a 4790K stephan@stephanUbuntu:~$ /usr/lib/nux/unity_support_test --print OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Haswell Desktop OpenGL version string: 3.0 Mesa 10.5.9 Not software rendered: yes Not blacklisted: yes GLX fbconfig: yes GLX texture from pixmap: yes GL npot or rect textures: yes GL vertex program: yes GL fragment program: yes GL vertex buffer object: yes GL framebuffer object: yes GL version is 1.4+: yes Unity 3D supported: yes Thanks, Stephan
participants (11)
-
Alexandre Bergel -
Ben Coman -
Dimitris Chloupis -
Marcus Denker -
Offray Vladimir Luna Cárdenas -
phil＠highoctane.be -
Ronie Salgado -
Stephan Eggermont -
stepharo -
Tudor Girba -
Volkert