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