April 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Polygons + Skybox in woden?

by stepharo

Hi ronie > Sorry for not answering, this email got buried under my inbox. > > IIRC, Woden is built on modern GL techniques, and GL_POLYGON is > deprecated in 3.0, so I doubt it. > > By polygon, what do you mean?, an arbitrary concave polygon or a > convex polygon? For a convex polygon, you only need to use what is > known as a triangle fan. For a concave polygon, you need a constrained > Delaunay triangulation, which is an easy to explain but hard to > implement algorithm. I guess that GL_POLYGON only supports convex > polygons. > > For the convex case, take a look here: > http://en.wikipedia.org/wiki/Triangle_fan > I think that the code should be something like this; > > builder := WDGeometryBuilder ... > points := {}. > points do: [:p | builder addP: ...]. > indexBase = 1. > 3 to: points size: [:i | > builder addI: 1 i2: i - 1 i3: i3. > ]. Yes people should read and learn :). > > If you want the concave case, take a look into the incremental > Delaunay triangulation algorithm. Then, into adding the constrains > (edges of the polygon) to construct the constrained Delaunay > triangulation. Now, this is a 2D algorithm, so the points have to be > in a plane. Don even think on trying a 3D Delaunay triangulation, > because it is for volumes and not surface, and it is hellish. > > > I Woden still developed? > > Currently I do not have time to work in Woden, but when I get more > time, I will continue working on it. More time means after May, > because of studies and a paper that I am presenting in ICSE. JB is adding shadders :) and a ci server. He is improving the shadder versionning because he got blocked on mac. All the code we do for the Thales project will be pushed back into Woden. Thanks for this great software. > I Woden still developed? Because I thought that Object Profile was > working on it. Otherwise maybe we should switch to the CodeCity > engineâ¦ it seems to have more âsupportâ. > > > Now, I do not want to add many more low level features to Woden, until > I get a production ready version of Lowcode/uFFI, which is required to > optimize some really performance critical sections of Woden. With > Lowcode I am getting C like pointers in the VM with a small overhead > in comparison with nbFloat32AtOffset: and nbFloat32AtOffset:put: . > Pointers and C structures are required to fill buffers with an exact > memory layout, which is required by OpenGL 2+ . Nice nice nice. > The alternative to Lowcode or the NativeBoost x86-32 assembler, is to > move significant parts to C++. Moving significant parts to C++ means a > huge loss of flexibility, and it means a completely different engine. > Completely different, because I have been reading about more modern > game engines, and better design patterns such as Entity Component System. > > Anyway, one of the first thing that I am going to do when coming > really back to Woden, is to move it to GitHub. By using git I can fix > some part of the native library dependency hell. Bullet is used for > physics it is written in C++, and I am definitely not going to rewrite > in Smalltalk. > > Moreover, I would like to put some sort of skybox in my scene. > Apparently it's not possible yet, so my question is how could I do > that? > > > Skyboxes are in my TODO list. My biggest problem with sky-boxes are in > loading the cube map texture. A cube map texture is actually a single > texture that has six faces. The six faces of a cube. > > Skybox support requires loading a cube map texture, and then using a > special material for the sky with a special shader. > I am going to try getting a demo working in the weekend, it should not > be very complicated. It also gives me a good opportunity to rewrite > the shaders. I found a better way to embed shaders when working in the > VirtualGPU, by using the GTInspector. JB did you commit your changes? > > you want to reinvent all the effort ronie put in woden? > > It is more probably that the one reinventing and being successful > would be myself. Graphics programming is really hard, specially if we > are doing it in a completely dynamic language as Smalltalk or Pharo. I > have learned valuables lessons by reinventing my game/graphics engine > several time, and studying long time ago others game engines, such as > the good old Quake engine. Woden is not my first or second graphics > engine, I have already lost the count. I think it is about my > sixth/seven engine. And I still think that there's a lot of room that > I have improve, without rewriting everything. Excellent. Keep pushing. > > Do not expect to see a AAA game engine written completely in Pharo or > Smalltalk. The optimizations done in AAA engines simply cannot be done > in Smalltalk. They are designed with simple data structures that are > optimized to work well with CPU caches. There is also some heavy > inlining done by the C/C++ compiler. No garbage collection, just > manual and deterministic memory management. > > If you want to make a new engine, please be aware that the graphics > landscape is becoming quite interesting. Specially because this year > we are going to see Vulkan, which is the successor of OpenGL, and > Direct3D 12. Those new graphics API are said to be very low level in > comparison with OpenGL. According to Valve ( > http://www.phoronix.com/scan.php?page=article&item=valve-lunarg-vulkan&num=1 > ), writing a graphics engine for Vulkan is similar to writing a > graphics driver or developing for consoles. All of this requires heavy > support for pointers a la C. Argh. > > Best regards, > Ronie Salgado > > 2015-04-16 18:24 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com > <mailto:alexandre.bergel@me.com>>: > > > Uhh.. > > > > I Woden still developed? Because I thought that Object Profile > was working on it. Otherwise maybe we should switch to the > CodeCity engineâ¦ it seems to have more âsupportâ. > > Ronie? > > Alexandre > > > > >> On 16 Apr 2015, at 15:11, Alexandre Bergel > <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: > >> > >> No idea, but let us know! > >> > >> Alexandre > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > >>> On Apr 16, 2015, at 4:41 AM, Lusa Nicolas <nicolas.lusa(a)usi.ch > <mailto:nicolas.lusa@usi.ch>> wrote: > >>> > >>> Hello, > >>> > >>> I am Nicolas Lusa from university of Lugano and I am working > on my master thesis with the supervision of Yuriy Tymchuk. > >>> Right now I am working with woden and I am trying to build > polygons. > >>> Question1: Is it possible somehow to build polygons in woden? > >>> > >>> If not: > >>> I know woden is based on OpenGL and I also know that in OpenGL > is possible to draw polygons with GL_POLYGON and a given array of > points. > >>> Question2: How could I use GL_POLYGON through woden for my > purpose? > >>> > >>> Moreover, I would like to put some sort of skybox in my scene. > Apparently it's not possible yet, so my question is how could I do > that? > >>> > >>> Thanks in advance. > >>> Cheers. > >>> Nicolas > >> > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

April 18, 2015

Re: [Pharo-users] Fwd: Fwd: Debris' Quuve - Technologies used

by stepharo

Just a remark I found strange that not a single little improvements of Magritte was necessary for the Qude project. Now if heavy users of open-source libraries do not enhance these open-source libraries and keep their extensions under close source then the open-source libraries will never make progress and I will immensely sad. You know that I like business and that people can make money but the fight is against other community and competetitor and not within Pharo. Stef Le 17/4/15 19:43, Stephan Eggermont a Ã©crit : > On 16/04/15 16:33, Mariano Martinez Peck wrote: >> 1) We want everything to be ajaxfied (so every single component >> needed to be rewritten for AJAX) > > 2) We want all our components to use Bootstrap layout > > In QCMagritte we managed to keep most, using an Ajax-Memento and > the chained visitors. > >> 3) We want components/descriptions/renderes/etc that better fit our >> own needs >> 4) We needed more hooks > > Definitely. > >> We think Magritte was easy enough >> to extend as is. Another thing we found is that sometimes is a bit >> hard to agree on what is needed for all magritte users. So fully >> refactoring Magritte may affect other developers or other use-cases >> of Magritte. > > Yep, fully agree. > > Stephan > > >

April 18, 2015

Re: [Pharo-users] [ANN] Pharo 4.0 is released!

by volkert

Coooool! Yes, spread the Word. Is there a cool promotion flyer / booklet for Pharo? I found this here: http://files.pharo.org/media/flyer-cheat-sheet.pdf. Not really attractive ... Is there something better? BW, Volkert Am 16.04.2015 um 11:29 schrieb Esteban Lorenzano: > Please spread widely. > Sorry for multiple posts. >

April 18, 2015

Re: [Pharo-users] [ANN] Pharo 4.0 is released!

by Offray Vladimir Luna CÃ¡rdenas

Hi, I just join to the celebration and add my thanks to all. It has been a wonderful trip the last 10 months inhabiting again the Dynabook/Smalltalk/Pharo world. By the way, one of the nice things reading about the release on Hacker News was to find this reference: http://seandenigris.com/blog/?p=1092 Sean, if you're here, have you read Tracing the dynabook [1]? Your blog post are pretty evocative of several ideas in dialogue with that writing. [1] http://tkbr.ccsp.sfu.ca/dynabook/ Keep Pharo awesome! Offray El 16/04/15 a las 04:29, Esteban Lorenzano escribiÃ³: > Please spread widely. > Sorry for multiple posts. > > (this post can be see here: http://pharo.org/news/pharo-4.0-released) > > Dear World, > > Pharo 4.0 (http://www.pharo.org) is here. > > Pharo is a pure object-oriented programming language and a powerful environment, > focused on simplicity and immediate feedback. > > Many things have changed in Pharo. Here are some highlights: > - Inspector/Playground/Spotter are new moldable development tools for > inspecting, coding and searching objects. > - Slots model instance variables as first class entities and enable > meta-programming on this level. > - ShoreLine reporter introduces a way to report system errors and collect > statistics, that we will use for future improvements > - Dark theme. > > These are just the more prominent highlights, but the details are just as > important. We have closed 1697 issues in Pharo 4. Take a moment to go through a > more detailed recount of the progress: > > https://github.com/pharo-project/ChangeLogs/blob/master/Pharo40ChangeLogs.md > > Pharo is improving on many fronts, but one of the most prominent changes is the > addition of moldable tools for inspection and search. These tools provide > extension mechanisms that allow every object to define ways in which it can be > understood effectively. To provide an idea of the impact of the already existing > extensions, the map below shows the Pharo classes grouped in packages, > highlighting in red those parts of the system that have at least one such custom > view coming with the main distribution. The spread of these extensions shows > that moldability is powerful mechanism that can be used in many contexts. > > > Remember that Pharo is your platform. We thank all the contributors of this > release: > > Clara Allende, Jean-Baptiste Arnaud, Jean-Christophe Bach, Philippe Back, > Clement Bera, Alexandre Bergel, Torsten Bergmann, Vincent Blondeau, Noury > Bouraqadi, Santiago Bragagnolo, Johan Brichau, Sven Van Caekenberghe, Damien > Cassou, Nicolas Cellier, Guido Chari, Dimitris Chloupis, Andrei Chis, Ben Coman, > Bernardo Contreras, Tommaso Dal Sasso, Jan Van De Sandt, Christophe Demarey, > Sean DeNigris, Marcus Denker, Martin Dias, Stephane Ducasse, Stephan Eggermont, > Luc Fabresse, Johan Fabry, Hilaire Fernandes, Jerome Garcia, Tudor Girba, > Thierry Goubier, Jigyasa Grover, Kris Gybels, Norbert Hartl, Dale Henrichs, > Pablo Herrero, Nicolai Hess, Pavel Krivanek, Juraj Kubelka, Jan Kurs, Laurent > Laffont, Jannik Laval, Kevin Lanvin, Max Leske, David Lewis, Diego Lont, Esteban > Lorenzano, Tim Mackinnon, Attila Magyar, Esteban Maringolo, Stefan Marr, Max > Mattone, Martin Mc Clure, Eliot Miranda, Alain Plantec, Guillermo Polito, Damien > Pollet, Stefan Reichhart, Mark Rizun, Udo Schneider, Ignacio Sniechowski, Henrik > Sperre Johansen, Igor Stasenko, Aliaksei Syrel, Ciprian Teodorov, Camille > Teruel, Sebastian Tleye, Yuriy Tymchuk, Peter Uhnak, Andres Valloud, Sven Van > Caekenberghe, Thomas Vincent, Jan Vrany, Martin Walk, Richard Wettel, Dmitri > Zagidulin > > And all those who contributed indirectly, by reporting bugs, participating in > discussion threads, providing feedback... > > Pharo 4.0 is another big step. And, the best is yet to come. > > Enjoy! > The Pharo Team >

April 17, 2015

Re: [Pharo-users] [Gitfiletree] Loading development version failed

by Jan BlizniÄenko

Yes it does, thanks! Jan Thierry Goubier wrote > Hi Jan, > > I think I fixed it. It should work now. > > Thierry -- View this message in context: http://forum.world.st/Gitfiletree-Loading-development-version-failed-tp4820… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 17, 2015

Re: [Pharo-users] [Gitfiletree] Loading development version failed

by Thierry Goubier

Hi Jan, I think I fixed it. It should work now. Thierry Le 17/04/2015 20:06, Jan BlizniÄenko a Ã©crit : > Hello > > Today I tried loading development version of GitGileTree, but received > error: > > MetacelloProjectSpecLoadError: No version found for #'4.5.11' of > ConfigurationOfOSProcess because: The symbolic version #'4.5.11' is not > defined in ConfigurationOfOSProcess for the current platform. Possible > symbolic version values include: #(#bleedingEdge #stable) > > Loading code is: > > Gofer new > url: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo40/main'; > configurationOf: 'GitFileTree'; > loadDevelopment. > > Stable version loads fine. > > Jan > > > > -- > View this message in context: http://forum.world.st/Gitfiletree-Loading-development-version-failed-tp4820… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > >

April 17, 2015

Re: [Pharo-users] Roasal: Putting a white background instead of a transparent one in word clouds

by Jan BlizniÄenko

Thanks for reminding me, Peter... I wrote a mail about this few months before, but it seems I made a mistake and didn't include mailing list and sent it only to (one of) Alex's personal mail address. So, I will copy paste (and rewrite a little) it here. Hi Alex After some time I finally looked how my DCTRCanvasExporter is used in Roassal. I'm glad it found use even in Roassal itself, but there are few minor things I'd like to change anyway. I used to have mcz when I wrote that mentioned mail, but now it would make milion of conflicts so I will do new one according to your answer to this mail. First, I added few comments and made minor changes in code (however, "interface" and general behavior didn't change except of moving example method to class side). Second, it's not much of a problem, but in the class name, DCTRCanvasExporter, the "DC" letters we use to indicate it is part of our project, DynaCASE, but since it became part of whole roassal, I think the "DC" is not appropriate anymore there. And last one is more of a question than anything else... You included it into Roassal package, but it works entirely on Trachel level, wouldn't Trachel package be more appropriate? Jan Peter UhnÃ¡k wrote > Alex: could you please rename DCTRCanvasExporter to TRCanvasExporter? Or > whatever you fancy, but without the DC prefix. This was mentioned before > by > Jan but probably got lost somewhere. > > Peter -- View this message in context: http://forum.world.st/Roasal-Putting-a-white-background-instead-of-a-transp… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 17, 2015

Re: [Pharo-users] Roasal: Putting a white background instead of a transparent one in word clouds

by Peter UhnÃ¡k

> > There is any other way I can help with debugging this? Should I open a bug > report to get this solved on Roassal? > This is best directed at Alex, but I would think that the solution should be pretty straight forward (maybe just copying part of the solution between the exporters). Alex: could you please rename DCTRCanvasExporter to TRCanvasExporter? Or whatever you fancy, but without the DC prefix. This was mentioned before by Jan but probably got lost somewhere. Peter

April 17, 2015

Re: [Pharo-users] Roasal: Putting a white background instead of a transparent one in word clouds

by Offray Vladimir Luna CÃ¡rdenas

Peter, Thanks for your quick response and sorry for my late one. I give a try of your solution, but implemented them in my visualization process would take more time that the one I had available, so finally I went with the graphics editor solution. There is any other way I can help with debugging this? Should I open a bug report to get this solved on Roassal? Cheers, Offray El 13/04/15 a las 11:08, Peter UhnÃ¡k escribiÃ³: > I think there is a bug in the exporter, because the canvas has a color (which is > white and _not_ transparent). > Normally you can set the color of the of the canvas (view canvas color: Color > purple), but the default exporter (I assume you are exporting it via > GT-inspector) is ignoring it. > There is however second exporter which you can use > > ~~~~~~~~~~~~~~~~~~~~~ > |v fileName| > v := RTView new. > v canvas color: Color purple. > v addAll: (RTEllipse new color: Color black; size: 30; elementsOn: (1 to: 10)). > RTCircleLayout on: v elements. > > fileName := UITheme builder > fileSave: 'Enter the PNG file name' > extensions: #('png') > path: nil. > "fileName := '/tmp/test.png' asFileReference." > fileName notNil ifTrue: [ > (DCTRCanvasExporter canvas: v canvas) > format: #png; > fileName: fileName fullName; > export ]. > > v > ~~~~~~~~~~~~~~~~~~~~~~~ > > You could also add the export code (with minor modification) to > GLMRoassal2Presentation>>defaultActions but there seems to be some kind of bug > that clears the content of the playground when executed from GLM, which is a big > wtf, but maybe that's just my mixed up configuration. > > Peter > > > On Mon, Apr 13, 2015 at 5:17 PM, Offray Vladimir Luna CÃ¡rdenas > <offray(a)riseup.net <mailto:offray@riseup.net>> wrote: > > Hi, > > I have finally finished the first part of my visualization project of > political discourses on Twitter. You can see the details here: > > http://mutabit.com/offray/__static/blog/output/posts/__visualizing-__politi… > <http://mutabit.com/offray/static/blog/output/posts/visualizing-politiciansp…> > > (As you can see Pharo was not used to extract the data, just to scrap it, > structure it and visualize it). > > The politicians tag cloud look nice if the background is white, because the > png background is transparent, but if you share it on Twitter, the black > background makes the tag cloud invisible. I could use image editing programs > to change the background from transparent to white, but I would like to know > if there is a way to make that change inside Pharo/Roasal. > > Thanks for all your support in making this ideas possible. > > Cheers, > > Offray > >

April 17, 2015

Re: [Pharo-users] Polygons + Skybox in woden?

by Ronie Salgado

Sorry for not answering, this email got buried under my inbox. IIRC, Woden is built on modern GL techniques, and GL_POLYGON is deprecated > in 3.0, so I doubt it. By polygon, what do you mean?, an arbitrary concave polygon or a convex polygon? For a convex polygon, you only need to use what is known as a triangle fan. For a concave polygon, you need a constrained Delaunay triangulation, which is an easy to explain but hard to implement algorithm. I guess that GL_POLYGON only supports convex polygons. For the convex case, take a look here: http://en.wikipedia.org/wiki/Triangle_fan I think that the code should be something like this; builder := WDGeometryBuilder ... points := {}. points do: [:p | builder addP: ...]. indexBase = 1. 3 to: points size: [:i | builder addI: 1 i2: i - 1 i3: i3. ]. If you want the concave case, take a look into the incremental Delaunay triangulation algorithm. Then, into adding the constrains (edges of the polygon) to construct the constrained Delaunay triangulation. Now, this is a 2D algorithm, so the points have to be in a plane. Don even think on trying a 3D Delaunay triangulation, because it is for volumes and not surface, and it is hellish. > > I Woden still developed? Currently I do not have time to work in Woden, but when I get more time, I will continue working on it. More time means after May, because of studies and a paper that I am presenting in ICSE. I Woden still developed? Because I thought that Object Profile was working > on it. Otherwise maybe we should switch to the CodeCity engineâ¦ it seems to > have more âsupportâ. > > Now, I do not want to add many more low level features to Woden, until I get a production ready version of Lowcode/uFFI, which is required to optimize some really performance critical sections of Woden. With Lowcode I am getting C like pointers in the VM with a small overhead in comparison with nbFloat32AtOffset: and nbFloat32AtOffset:put: . Pointers and C structures are required to fill buffers with an exact memory layout, which is required by OpenGL 2+ . The alternative to Lowcode or the NativeBoost x86-32 assembler, is to move significant parts to C++. Moving significant parts to C++ means a huge loss of flexibility, and it means a completely different engine. Completely different, because I have been reading about more modern game engines, and better design patterns such as Entity Component System. Anyway, one of the first thing that I am going to do when coming really back to Woden, is to move it to GitHub. By using git I can fix some part of the native library dependency hell. Bullet is used for physics it is written in C++, and I am definitely not going to rewrite in Smalltalk. Moreover, I would like to put some sort of skybox in my scene. Apparently > it's not possible yet, so my question is how could I do that? Skyboxes are in my TODO list. My biggest problem with sky-boxes are in loading the cube map texture. A cube map texture is actually a single texture that has six faces. The six faces of a cube. Skybox support requires loading a cube map texture, and then using a special material for the sky with a special shader. I am going to try getting a demo working in the weekend, it should not be very complicated. It also gives me a good opportunity to rewrite the shaders. I found a better way to embed shaders when working in the VirtualGPU, by using the GTInspector. you want to reinvent all the effort ronie put in woden? It is more probably that the one reinventing and being successful would be myself. Graphics programming is really hard, specially if we are doing it in a completely dynamic language as Smalltalk or Pharo. I have learned valuables lessons by reinventing my game/graphics engine several time, and studying long time ago others game engines, such as the good old Quake engine. Woden is not my first or second graphics engine, I have already lost the count. I think it is about my sixth/seven engine. And I still think that there's a lot of room that I have improve, without rewriting everything. Do not expect to see a AAA game engine written completely in Pharo or Smalltalk. The optimizations done in AAA engines simply cannot be done in Smalltalk. They are designed with simple data structures that are optimized to work well with CPU caches. There is also some heavy inlining done by the C/C++ compiler. No garbage collection, just manual and deterministic memory management. If you want to make a new engine, please be aware that the graphics landscape is becoming quite interesting. Specially because this year we are going to see Vulkan, which is the successor of OpenGL, and Direct3D 12. Those new graphics API are said to be very low level in comparison with OpenGL. According to Valve ( http://www.phoronix.com/scan.php?page=article&item=valve-lunarg-vulkan&num=1 ), writing a graphics engine for Vulkan is similar to writing a graphics driver or developing for consoles. All of this requires heavy support for pointers a la C. Best regards, Ronie Salgado 2015-04-16 18:24 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > > Uhh.. > > > > I Woden still developed? Because I thought that Object Profile was > working on it. Otherwise maybe we should switch to the CodeCity engineâ¦ it > seems to have more âsupportâ. > > Ronie? > > Alexandre > > > > >> On 16 Apr 2015, at 15:11, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > >> > >> No idea, but let us know! > >> > >> Alexandre > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > >>> On Apr 16, 2015, at 4:41 AM, Lusa Nicolas <nicolas.lusa(a)usi.ch> wrote: > >>> > >>> Hello, > >>> > >>> I am Nicolas Lusa from university of Lugano and I am working on my > master thesis with the supervision of Yuriy Tymchuk. > >>> Right now I am working with woden and I am trying to build polygons. > >>> Question1: Is it possible somehow to build polygons in woden? > >>> > >>> If not: > >>> I know woden is based on OpenGL and I also know that in OpenGL is > possible to draw polygons with GL_POLYGON and a given array of points. > >>> Question2: How could I use GL_POLYGON through woden for my purpose? > >>> > >>> Moreover, I would like to put some sort of skybox in my scene. > Apparently it's not possible yet, so my question is how could I do that? > >>> > >>> Thanks in advance. > >>> Cheers. > >>> Nicolas > >> > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

April 17, 2015