[ANN] Ephestos - Using and Coding Blender from inside Pharo
Its far from production ready but I am too excited to keep to myself. I present to you Ephestos. Ephestos is a socket bridge that communicates with Blender the most popular and most powerful open source 3d application. http://www.blender.org/ The goal is to expose Blender coders to the power of Pharo and Pharo to the power of Blender. As you can imagine the potential is huge but I rather talk what Ephestos can do already. Even though Ephestos is in total less than 200 lines of code it can already communicate with blender and affect blender properties. Blender properties are basically instance variables for any kind of blender object, 3d object, material, textures etc So already you can affect a huge deal of blender . Unfortunately Blender operators seem to crash Blender , probably I am doing something stupid that I will fix. Blender operators are for performing blender actions so they are very important. I have made a simple video demo of it that can be watched here https://www.youtube.com/watch?v=8igk9DoY6PU&feature=youtu.be To use it you need first the Blender addon which can be found here https://github.com/kilon/pyEphestos The code should be inside a folder named "pyEphestos" and placed in Blender addons directory which is located for Macos in Application Support/Blender/VersionsOfBlender/scripts/addons and in Windows should be in App Data/Roaming/..... or you can place it inside the blender folder in similar sub directory You also need the Pharo code which can be found here http://www.smalltalkhub.com/#!/~kilon/Ephestos/ As I said it is far from production ready , but it works. The good news is that the socket communication is blazing fast, at least compared to what I expected. I was able to perform 1000 connections under a second. And each connection carries a 1024 bytes messages , thats a lot of code. Should be possible to pass thousands of lines of code under a second to Blender. My only worry is blender itself since it tends to be very crashy in the areas I am pushing. By the way Always press esc after you enable Ephestos in Blender to close the socket or else it wont free it and next time you wont be able to open the socket and you will have to restart your OS. And do not make an error with the string passed . I need to add an exception for it so it wont crash blender.
kilon alios wrote
The goal is to expose Blender coders to the power of Pharo and Pharo to the power of Blender
Cool! I want this :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/ANN-Ephestos-Using-and-Coding-Blender-from-inside-Phar... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
don't worry more is coming :) On Wed, Jul 16, 2014 at 5:25 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
kilon alios wrote
The goal is to expose Blender coders to the power of Pharo and Pharo to the power of Blender
Cool! I want this :)
----- Cheers, Sean -- View this message in context: http://forum.world.st/ANN-Ephestos-Using-and-Coding-Blender-from-inside-Phar... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I don't have time to play, but this looks very very cool. At a minimum, its a great demonstration of Pharo/Smalltalk playing-well-with-others. Some feedback on the video presentation, zooming in on the workspace to make the text more readable in low-def video streams, then zooming out just before it is executed would be useful. cheers -ben kilon alios wrote:
Its far from production ready but I am too excited to keep to myself. I present to you Ephestos.
Ephestos is a socket bridge that communicates with Blender the most popular and most powerful open source 3d application.
The goal is to expose Blender coders to the power of Pharo and Pharo to the power of Blender. As you can imagine the potential is huge but I rather talk what Ephestos can do already.
Even though Ephestos is in total less than 200 lines of code it can already communicate with blender and affect blender properties. Blender properties are basically instance variables for any kind of blender object, 3d object, material, textures etc So already you can affect a huge deal of blender .
Unfortunately Blender operators seem to crash Blender , probably I am doing something stupid that I will fix. Blender operators are for performing blender actions so they are very important.
I have made a simple video demo of it that can be watched here
https://www.youtube.com/watch?v=8igk9DoY6PU&feature=youtu.be <https://www.youtube.com/watch?v=8igk9DoY6PU&feature=youtu.be>
To use it you need first the Blender addon which can be found here
https://github.com/kilon/pyEphestos
The code should be inside a folder named "pyEphestos" and placed in Blender addons directory which is located for Macos in Application Support/Blender/VersionsOfBlender/scripts/addons and in Windows should be in App Data/Roaming/..... or you can place it inside the blender folder in similar sub directory
You also need the Pharo code which can be found here
http://www.smalltalkhub.com/#!/~kilon/Ephestos/ <http://www.smalltalkhub.com/#%21/%7Ekilon/Ephestos/>
As I said it is far from production ready , but it works.
The good news is that the socket communication is blazing fast, at least compared to what I expected. I was able to perform 1000 connections under a second. And each connection carries a 1024 bytes messages , thats a lot of code. Should be possible to pass thousands of lines of code under a second to Blender.
My only worry is blender itself since it tends to be very crashy in the areas I am pushing.
By the way Always press esc after you enable Ephestos in Blender to close the socket or else it wont free it and next time you wont be able to open the socket and you will have to restart your OS. And do not make an error with the string passed . I need to add an exception for it so it wont crash blender.
I am apologize about the video , I recorded it in 720p and forgot to increase the pharo font size. But worry not, Ephestos will come with an array of examples to help you understand the whole process and get you started. I will upload shortly the examples used in the videos. On Wed, Jul 16, 2014 at 5:53 PM, Ben Coman <btc@openinworld.com> wrote:
I don't have time to play, but this looks very very cool. At a minimum, its a great demonstration of Pharo/Smalltalk playing-well-with-others.
Some feedback on the video presentation, zooming in on the workspace to make the text more readable in low-def video streams, then zooming out just before it is executed would be useful.
cheers -ben
kilon alios wrote:
Its far from production ready but I am too excited to keep to myself. I present to you Ephestos. Ephestos is a socket bridge that communicates with Blender the most popular and most powerful open source 3d application. http://www.blender.org/
The goal is to expose Blender coders to the power of Pharo and Pharo to the power of Blender. As you can imagine the potential is huge but I rather talk what Ephestos can do already. Even though Ephestos is in total less than 200 lines of code it can already communicate with blender and affect blender properties. Blender properties are basically instance variables for any kind of blender object, 3d object, material, textures etc So already you can affect a huge deal of blender .
Unfortunately Blender operators seem to crash Blender , probably I am doing something stupid that I will fix. Blender operators are for performing blender actions so they are very important.
I have made a simple video demo of it that can be watched here
https://www.youtube.com/watch?v=8igk9DoY6PU&feature=youtu.be < https://www.youtube.com/watch?v=8igk9DoY6PU&feature=youtu.be>
To use it you need first the Blender addon which can be found here
https://github.com/kilon/pyEphestos
The code should be inside a folder named "pyEphestos" and placed in Blender addons directory which is located for Macos in Application Support/Blender/VersionsOfBlender/scripts/addons and in Windows should be in App Data/Roaming/..... or you can place it inside the blender folder in similar sub directory
You also need the Pharo code which can be found here
http://www.smalltalkhub.com/#!/~kilon/Ephestos/ < http://www.smalltalkhub.com/#%21/%7Ekilon/Ephestos/>
As I said it is far from production ready , but it works. The good news is that the socket communication is blazing fast, at least compared to what I expected. I was able to perform 1000 connections under a second. And each connection carries a 1024 bytes messages , thats a lot of code. Should be possible to pass thousands of lines of code under a second to Blender. My only worry is blender itself since it tends to be very crashy in the areas I am pushing. By the way Always press esc after you enable Ephestos in Blender to close the socket or else it wont free it and next time you wont be able to open the socket and you will have to restart your OS. And do not make an error with the string passed . I need to add an exception for it so it wont crash blender.
2014-07-16 12:16 GMT-03:00 kilon alios <kilon.alios@gmail.com>:
I am apologize about the video , I recorded it in 720p and forgot to increase the pharo font size. But worry not, Ephestos will come with an array of examples to help you understand the whole process and get you started. I will upload shortly the examples used in the videos.
One suggestion about the edition of the video. Show some of the results during the first 30 seconds, and then explain the whole process to get there. It's like the cooking shows, where they show the cake already made, and then the whole process to make it. Otherwise it gets longwinded, because you don't know when the "peak moment" will take place. Having said that. What you did is really cool. I used to 3D in the past (with Caligari trueSpace), and back then I'd love to have something like Pharo to program it (trueSpace started used Phyton too). Regards!
I am a huge fan of Truespace and ZBrush, so sad to see it die :( Another big love was Softimage XSI, dead too. I started using Blender as soon as Autodesk bought Softimage because I predicted that its days were numbered. I completely agree on the format of the video, next time I will have separate video for installation and another for features so it is shorter and to the point. On Wed, Jul 16, 2014 at 6:27 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2014-07-16 12:16 GMT-03:00 kilon alios <kilon.alios@gmail.com>:
I am apologize about the video , I recorded it in 720p and forgot to increase the pharo font size. But worry not, Ephestos will come with an array of examples to help you understand the whole process and get you started. I will upload shortly the examples used in the videos.
One suggestion about the edition of the video. Show some of the results during the first 30 seconds, and then explain the whole process to get there. It's like the cooking shows, where they show the cake already made, and then the whole process to make it. Otherwise it gets longwinded, because you don't know when the "peak moment" will take place.
Having said that. What you did is really cool. I used to 3D in the past (with Caligari trueSpace), and back then I'd love to have something like Pharo to program it (trueSpace started used Phyton too).
Regards!
On Jul 16, 2014, at 12:27 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
One suggestion about the edition of the video. Show some of the results during the first 30 seconds, and then explain the whole process to get there. It's like the cooking shows, where they show the cake already made, and then the whole process to make it.
+1 about using that format. First and quick you show the what, then you take your time to show the how in all its details Congratulations for achieving that, youâre doing a great job and there is huge potential in it! sebastian o/ blog: http://sebastianconcept.com LinkedIn: http://www.linkedin.com/in/sebastiansastre github: https://github.com/sebastianconcept
On Wed, Jul 16, 2014 at 5:27 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Caligari trueSpace
I learned 3D with TrueSpace and loved it. The company doing it was working in a neighbor city near Bordeaux, France. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
On Tue, Jul 15, 2014 at 11:09 PM, kilon alios <kilon.alios@gmail.com> wrote:
The goal is to expose Blender coders to the power of Pharo and Pharo to the power of Blender. As you can imagine the potential is huge but I rather talk what Ephestos can do already.
That's great kilon! I can't wait to see how far you could go with that. I hope you plan to use Pharo syntax instead of plain string for the messages. A message like this: "bpy.data.objects["Cube"].location = (0.0, 0.0, 0.0)" could be written like that: (EphestosMessage bpy data objects: 'Cube') location: (EphestosLocation x: 0 y: 0 z: 0) or something similar -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
yes the one I am considering as strong candidate is (BPYObjects at: 'Cube' ) location : #( 0 0 0 ) I would try to simplify bpy ( Blender Python API) and make it a lot more pharo friendly. However plain python string will be kept as well, so you can copy paste existing python code. One thing to note here is that Blender python addons are a huge deal. Python addons are actually full blown python apps. Blender python is basically a regular cpython 3 which is by far the most popular python implementation , meaning not only that you can use blender api object but any python library you can find. As a pharo developer you also can tap into this power via Ephestos. something that I forgot to mention in the video, in the github repo there is a rawcode.py. This is a strip down version of the Blender code that will separate to its own project that I am naming "Atlas". The goal of Atlas, is to create a two way communication socket bridge between cpython (most popular python implementation) and pharo. Very similar to Ephestos but you will no longer need Blender. That means that pharo coders will be able to use python libraries from inside pharo and even mix python with pharo code. So you could make part of your application in python and part in pharo and still function as a single application. If I find the time I would like to expand Atlas to other languages too, so that pharo can take advantage of any library written in any language without the trouble of FFIs. But most likely I will stick to python and let others do the work. But even with just python as you imagine python is extremely popular and quite friendly with the pharo way of thinking. Meaning that in python its all about live objects too. Pharo will be able to tap into thousands of powerful python libraries.  I reserve some doubts to the amount of problems I will have to face to accomplish this and I am no way claiming it wont be a long process but so far through these very first steps the idea seems to go well in practice. On Wed, Jul 16, 2014 at 5:55 PM, Damien Cassou <damien.cassou@gmail.com> wrote:
On Tue, Jul 15, 2014 at 11:09 PM, kilon alios <kilon.alios@gmail.com> wrote:
The goal is to expose Blender coders to the power of Pharo and Pharo to
the
power of Blender. As you can imagine the potential is huge but I rather talk what Ephestos can do already.
That's great kilon! I can't wait to see how far you could go with that. I hope you plan to use Pharo syntax instead of plain string for the messages. A message like this:
"bpy.data.objects["Cube"].location = (0.0, 0.0, 0.0)"
could be written like that:
(EphestosMessage bpy data objects: 'Cube') location: (EphestosLocation x: 0 y: 0 z: 0)
or something similar
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
2014-07-16 12:31 GMT-03:00 kilon alios <kilon.alios@gmail.com>:
yes the one I am considering as strong candidate is
(BPYObjects at: 'Cube' ) location : #( 0 0 0 )
Why not BPYCube?
I would try to simplify bpy ( Blender Python API) and make it a lot more pharo friendly.
However plain python string will be kept as well, so you can copy paste existing python code.
One thing to note here is that Blender python addons are a huge deal. Python addons are actually full blown python apps. Blender python is basically a regular cpython 3 which is by far the most popular python implementation , meaning not only that you can use blender api object but any python library you can find. As a pharo developer you also can tap into this power via Ephestos.
something that I forgot to mention in the video, in the github repo there is a rawcode.py. This is a strip down version of the Blender code that will separate to its own project that I am naming "Atlas".
The goal of Atlas, is to create a two way communication socket bridge between cpython (most popular python implementation) and pharo. Very similar to Ephestos but you will no longer need Blender. That means that pharo coders will be able to use python libraries from inside pharo and even mix python with pharo code. So you could make part of your application in python and part in pharo and still function as a single application.
I am interested in Atlas. Do you have a link?
If I find the time I would like to expand Atlas to other languages too, so that pharo can take advantage of any library written in any language without the trouble of FFIs. But most likely I will stick to python and let others do the work.
But even with just python as you imagine python is extremely popular and quite friendly with the pharo way of thinking. Meaning that in python its all about live objects too. Pharo will be able to tap into thousands of powerful python libraries. 
I reserve some doubts to the amount of problems I will have to face to accomplish this and I am no way claiming it wont be a long process but so far through these very first steps the idea seems to go well in practice.
On Wed, Jul 16, 2014 at 5:55 PM, Damien Cassou <damien.cassou@gmail.com> wrote:
On Tue, Jul 15, 2014 at 11:09 PM, kilon alios <kilon.alios@gmail.com> wrote:
The goal is to expose Blender coders to the power of Pharo and Pharo to
the
power of Blender. As you can imagine the potential is huge but I rather talk what Ephestos can do already.
That's great kilon! I can't wait to see how far you could go with that. I hope you plan to use Pharo syntax instead of plain string for the messages. A message like this:
"bpy.data.objects["Cube"].location = (0.0, 0.0, 0.0)"
could be written like that:
(EphestosMessage bpy data objects: 'Cube') location: (EphestosLocation x: 0 y: 0 z: 0)
or something similar
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
The goal of Atlas, is to create a two way communication socket bridge between cpython (most popular python implementation) and pharo. Very similar to Ephestos but you will no longer need Blender. That means that pharo coders will be able to use python libraries from inside pharo and even mix python with pharo code. So you could make part of your application in python and part in pharo and still function as a single application.
I am interested in Atlas. Do you have a link?
This has been done some three years ago for OpenQwak :-) http://squeakingalong.wordpress.com/2011/05/04/openqwaq-python-integration/ Best, Jan
Does it work with Pharo ? I downloaded the documentation and is really well written. But I have no clue how to test with Pharo. Communication of languages and apps through sockets is nothing original or rare. I was actually considering expanding Atlas to not only talk to python but also talk to Pharo as well. My goal is to make pharo take advantage of multi core cpus. Each new instance of Pharo takes on core because this is how OS works with processes and Atlas could act as a net of communication between different instances of Pharo. Possible its an idea I wont work on but its something I consider in the back of my head. But if its easy enough I may do it. On Thu, Jul 17, 2014 at 9:06 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
The goal of Atlas, is to create a two way communication socket
bridge between cpython (most popular python implementation) and pharo. Very similar to Ephestos but you will no longer need Blender. That means that pharo coders will be able to use python libraries from inside pharo and even mix python with pharo code. So you could make part of your application in python and part in pharo and still function as a single application.
I am interested in Atlas. Do you have a link?
This has been done some three years ago for OpenQwak :-)
http://squeakingalong.wordpress.com/2011/05/04/ openqwaq-python-integration/
Best, Jan
hi guys Ephestos has been moving forward and I am happy to report I can finally offer 100% accessibility to Blender Python API , meaning you can have access to any blender operator and property. Additionally Ephestos won't crash anymore in case of python error, instead it will display the error in the Blender GUI , remove the message containing the error and carry on like nothing happened. Ephestos now offers full access to python globals, meaning you can assign global variables in python to shorten your code and for all the known benefits of using variables. With the help of Damien I was successful in creating a parser for pharo to python syntax. Using pharo messages you can now construct automagically python strings and pass it to blender . This way you no longer need to type in python syntax to do python stuff. So a big thanks to Damien. Note this method of course is slower because of parsing and heavy usage of regex string matching. You can watch a video demo here https://www.youtube.com/watch?v=yIE1LGjUDDA&feature=youtu.be This time I go straight to the practical examples and the video is much higher resolution and I use smaller windows to make the text look bigger so it should be much easier to watch and better to view than the previous demo. As I said Atlas will be released probably in a week or so and then I will like to work with QT from python http://qt-project.org/ QT is a great framework for GUIs , with designers, Support for Opengl , cross platform, true native look and looking gorgeous. Easily one of the most popular GUI APIs out there. I will wrap it with Atlas very similarly to Blender and offer it as a library called , QTPharo. Of course there will be more improvements coming for Ephestos. On Thu, Jul 17, 2014 at 11:25 PM, kilon alios <kilon.alios@gmail.com> wrote:
Does it work with Pharo ? I downloaded the documentation and is really well written. But I have no clue how to test with Pharo.
Communication of languages and apps through sockets is nothing original or rare.
I was actually considering expanding Atlas to not only talk to python but also talk to Pharo as well. My goal is to make pharo take advantage of multi core cpus. Each new instance of Pharo takes on core because this is how OS works with processes and Atlas could act as a net of communication between different instances of Pharo. Possible its an idea I wont work on but its something I consider in the back of my head. But if its easy enough I may do it.
On Thu, Jul 17, 2014 at 9:06 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
The goal of Atlas, is to create a two way communication socket
bridge between cpython (most popular python implementation) and pharo. Very similar to Ephestos but you will no longer need Blender. That means that pharo coders will be able to use python libraries from inside pharo and even mix python with pharo code. So you could make part of your application in python and part in pharo and still function as a single application.
I am interested in Atlas. Do you have a link?
This has been done some three years ago for OpenQwak :-)
http://squeakingalong.wordpress.com/2011/05/04/ openqwaq-python-integration/
Best, Jan
On Sun, Jul 20, 2014 at 7:34 PM, kilon alios <kilon.alios@gmail.com> wrote:
With the help of Damien I was successful in creating a parser for pharo to python syntax. Using pharo messages you can now construct automagically python strings and pass it to blender . This way you no longer need to type in python syntax to do python stuff. So a big thanks to Damien. Note this method of course is slower because of parsing and heavy usage of regex string matching.
are you sure you need to pass 'nil' everywhere? In #doesNotUnderstand:, you could check for the number of arguments and generate something appropriate based on that. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
well so far I don't know how to do this for example is I sent EphParser bpy data materials:'["Material"]' diffuse_color: '=(1.0,0.0,0.0)'. bpy is sent to doesNotUnderstand: but data is sent to Object cause the debugger complains that Message(Object)>>messageNotUnderstood Another problem is that even if I get this to work how I know where the python command ends ? Where is the period that separate command statements ? Without knowing where the command statement end I cannot formulate correct python strings. The advantage of sending the whole thing as a single keyword message is that I know its one unit and its easy to parse it to a string since the whole thing gets passed to doesNotUnderstand message as argument. I am no expert on pharo so if anyone has better idea I am open to suggestions as I said also in the video. On Sun, Jul 20, 2014 at 10:06 PM, Damien Cassou <damien.cassou@gmail.com> wrote:
On Sun, Jul 20, 2014 at 7:34 PM, kilon alios <kilon.alios@gmail.com> wrote:
With the help of Damien I was successful in creating a parser for pharo to python syntax. Using pharo messages you can now construct automagically python strings and pass it to blender . This way you no longer need to type in python syntax to do python stuff. So a big thanks to Damien. Note this method of course is slower because of parsing and heavy usage of regex string matching.
are you sure you need to pass 'nil' everywhere? In #doesNotUnderstand:, you could check for the number of arguments and generate something appropriate based on that.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
Yeah !!! I did it !!! :D Apparently I was doing it wrong , by returning the message in doesNotUnderstand , this is why the next MNU was returned by Object instead of my parser class. Say bye bye to ugly nil syntax , Ephestos now supports normal pharo messaging. This ugly thing EphParser bpy:nil data:nil objects:'[ "Cube" ]' location: '=(0.0,0.0,0.0)' . has turned to this EphCParser bpy ; data ; objects:'["Cube"]' location:'=(0.0,0.0,0.0)' ; e. or this EphCParser bpy data objects:'["Cube"]' location:'=(0.0,0.0,0.0)'; e. or you can use parentheses . You can send all keywords as single message as I do in the example or separate them with parentheses to different messages , it does not matter because the parser unites them into a single string anyway. Message e, formulates the python string and marks the end of pharo command. Means that now I offer full python support with no weird pharo syntax :) New parser is called EphCParser if you want to give it a try, I am still working on it to make sure it works well in all scenarios. this is an example of using python globals for making the code shorter EphCParser x:'=1.0' ; e. EphCParser cube:'=bpy.data.objects["Cube"]';e. EphCParser cube ; location:'=(x,0.0,0.0)' ; e. You may wonder , "why not use pharo variables instead ?" . Well you can do that too ;) cube := EphCParser bpy data objects:'["Cube"]'. cube location:'=(x,0.0,0.0)' ; e. I will try to test the new parser a bit more and I will work on 1) receiving data from Blender 2) python errors triggering the pharo debugger and 3) buffer together multiple lines of python code for complex stuff like class and function definition etc 4) support BGE . On Sun, Jul 20, 2014 at 10:06 PM, Damien Cassou <damien.cassou@gmail.com> wrote:
On Sun, Jul 20, 2014 at 7:34 PM, kilon alios <kilon.alios@gmail.com> wrote:
With the help of Damien I was successful in creating a parser for pharo to python syntax. Using pharo messages you can now construct automagically python strings and pass it to blender . This way you no longer need to type in python syntax to do python stuff. So a big thanks to Damien. Note this method of course is slower because of parsing and heavy usage of regex string matching.
are you sure you need to pass 'nil' everywhere? In #doesNotUnderstand:, you could check for the number of arguments and generate something appropriate based on that.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
Documentation for Ephestos is now located here ---> https://www.gitbook.io/book/kilon/ephestos documentation will be kept updated with latest features from now on. I was succesfull in implementing python errors. Now Blender Python errors trigger the Pharo debugger that will allow you to fix the faulty code and resume as you do with regular Pharo code. I am also looking into Phratch to create a visual language for Ephestos. On Tue, Jul 22, 2014 at 2:35 AM, kilon alios <kilon.alios@gmail.com> wrote:
Yeah !!! I did it !!! :D
Apparently I was doing it wrong , by returning the message in doesNotUnderstand , this is why the next MNU was returned by Object instead of my parser class.
Say bye bye to ugly nil syntax , Ephestos now supports normal pharo messaging.
This ugly thing
EphParser bpy:nil data:nil objects:'[ "Cube" ]' location: '=(0.0,0.0,0.0)' .
has turned to this
EphCParser bpy ; data ; objects:'["Cube"]' location:'=(0.0,0.0,0.0)' ; e.
or this
EphCParser bpy data objects:'["Cube"]' location:'=(0.0,0.0,0.0)'; e.
or you can use parentheses . You can send all keywords as single message as I do in the example or separate them with parentheses to different messages , it does not matter because the parser unites them into a single string anyway. Message e, formulates the python string and marks the end of pharo command.
Means that now I offer full python support with no weird pharo syntax :) New parser is called EphCParser if you want to give it a try, I am still working on it to make sure it works well in all scenarios.
this is an example of using python globals for making the code shorter
EphCParser x:'=1.0' ; e. EphCParser cube:'=bpy.data.objects["Cube"]';e. EphCParser cube ; location:'=(x,0.0,0.0)' ; e.
You may wonder , "why not use pharo variables instead ?" . Well you can do that too ;)
cube := EphCParser bpy data objects:'["Cube"]'. cube location:'=(x,0.0,0.0)' ; e.
I will try to test the new parser a bit more and I will work on 1) receiving data from Blender 2) python errors triggering the pharo debugger and 3) buffer together multiple lines of python code for complex stuff like class and function definition etc 4) support BGE .
On Sun, Jul 20, 2014 at 10:06 PM, Damien Cassou <damien.cassou@gmail.com> wrote:
On Sun, Jul 20, 2014 at 7:34 PM, kilon alios <kilon.alios@gmail.com> wrote:
With the help of Damien I was successful in creating a parser for pharo to python syntax. Using pharo messages you can now construct automagically python strings and pass it to blender . This way you no longer need to type in python syntax to do python stuff. So a big thanks to Damien. Note this method of course is slower because of parsing and heavy usage of regex string matching.
are you sure you need to pass 'nil' everywhere? In #doesNotUnderstand:, you could check for the number of arguments and generate something appropriate based on that.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
On Sun, Jul 20, 2014 at 7:34 PM, kilon alios <kilon.alios@gmail.com> wrote:
hi guys Ephestos has been moving forward and I am happy to report I can finally offer 100% accessibility to Blender Python API , meaning you can have access to any blender operator and property.
Additionally Ephestos won't crash anymore in case of python error, instead it will display the error in the Blender GUI , remove the message containing the error and carry on like nothing happened.
Ephestos now offers full access to python globals, meaning you can assign global variables in python to shorten your code and for all the known benefits of using variables.
With the help of Damien I was successful in creating a parser for pharo to python syntax. Using pharo messages you can now construct automagically python strings and pass it to blender . This way you no longer need to type in python syntax to do python stuff. So a big thanks to Damien. Note this method of course is slower because of parsing and heavy usage of regex string matching.
You can watch a video demo here
https://www.youtube.com/watch?v=yIE1LGjUDDA&feature=youtu.be
Really great work Kilon. I was wondering if you could use such techniques in order to interact with MORSE, a 3D open-source robotics simulation engine based on top of Blender (mostly written in Python): https://www.openrobots.org/wiki/morse There is some information about how to build scenarios here: http://www.openrobots.org/morse/doc/latest/user/builder.html Might interest some people here. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
Well in theory it should work. I am saying "in theory" because I have not tried MORSE. What is Ephestos ? Basically its a python application that creates a streamsocket server that listens byte data, then it takes the byte messages it converts them to strings and it executes them using exec() built-in python function. The end. See what I did here , I did not mention Blender at all. Actually Ephestos is implemented as Blender addon. So it gives you both access to Bpy and python libraries. A Blender addon is basically a python application + access to BPY + extra stuff to make it easy to select and enable in the Blender GUI. Now from what I see at first glance MORSE uses BPY and BGE. BGE , the blender game engine is a separate app essentially with its own API. So I need to wrap Ephestos for BGE but it will still be the same thing with added more code to be called by BGE. It should be fairly easy to do and I will do it. I don't know if there are other implementation details about MORSE but I don't think there will be a problem to make it work with Ephestos. Of course Ephestos has still got some big limitations a) does not receive data from Blender b) does not support of multiline python code. I don't know about b) it may work already if you add newlines in your python strings and whitespaces but I will have to test this and of course improve it to make it easier to use. Both of these features will be added since they are high priority goals. On Mon, Jul 21, 2014 at 10:17 AM, Serge Stinckwich < serge.stinckwich@gmail.com> wrote:
On Sun, Jul 20, 2014 at 7:34 PM, kilon alios <kilon.alios@gmail.com> wrote:
hi guys Ephestos has been moving forward and I am happy to report I can finally offer 100% accessibility to Blender Python API , meaning you can have access to any blender operator and property.
Additionally Ephestos won't crash anymore in case of python error, instead it will display the error in the Blender GUI , remove the message containing the error and carry on like nothing happened.
Ephestos now offers full access to python globals, meaning you can assign global variables in python to shorten your code and for all the known benefits of using variables.
With the help of Damien I was successful in creating a parser for pharo to python syntax. Using pharo messages you can now construct automagically python strings and pass it to blender . This way you no longer need to type in python syntax to do python stuff. So a big thanks to Damien. Note this method of course is slower because of parsing and heavy usage of regex string matching.
You can watch a video demo here
https://www.youtube.com/watch?v=yIE1LGjUDDA&feature=youtu.be
Really great work Kilon.
I was wondering if you could use such techniques in order to interact with MORSE, a 3D open-source robotics simulation engine based on top of Blender (mostly written in Python): https://www.openrobots.org/wiki/morse There is some information about how to build scenarios here: http://www.openrobots.org/morse/doc/latest/user/builder.html Might interest some people here.
Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
On Mon, Jul 21, 2014 at 9:48 AM, kilon alios <kilon.alios@gmail.com> wrote:
Well in theory it should work.
I am saying "in theory" because I have not tried MORSE.
What is Ephestos ? Basically its a python application that creates a streamsocket server that listens byte data, then it takes the byte messages it converts them to strings and it executes them using exec() built-in python function. The end. See what I did here , I did not mention Blender at all. Actually Ephestos is implemented as Blender addon. So it gives you both access to Bpy and python libraries. A Blender addon is basically a python application + access to BPY + extra stuff to make it easy to select and enable in the Blender GUI.
Now from what I see at first glance MORSE uses BPY and BGE. BGE , the blender game engine is a separate app essentially with its own API. So I need to wrap Ephestos for BGE but it will still be the same thing with added more code to be called by BGE. It should be fairly easy to do and I will do it.
I don't know if there are other implementation details about MORSE but I don't think there will be a problem to make it work with Ephestos.
Of course Ephestos has still got some big limitations a) does not receive data from Blender b) does not support of multiline python code. I don't know about b) it may work already if you add newlines in your python strings and whitespaces but I will have to test this and of course improve it to make it easier to use. Both of these features will be added since they are high priority goals.
Thank you for your explanations Kilon. I understand better how it works now. Yes receiving data like perception data from robots is quite important for MORSE. One problem I envision, is that the data could be huge and some performance issues could appear I guess if you have to translate data structures from Python to Pharo. BTW, Noury and Luc developed a ROS binding for Pharo. ROS is a robotic middleware that could be used to do communication with MORSE. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
According to this http://stackoverflow.com/questions/9903670/measure-local-sockets-speed The speed for a modern computer should be around 200 mbs/sec , you can easily choke Pharo with this amount of data.I seriously doubt that Pharo can process 200mbs in 1 second. So it looks like you will worry about Pharo a lot sooner than you will worry about Ephestos. Also Ephestos because it allows you to execute any kind of python code, you have the option to let the data sit inside blender and fetch it whenever you want them or just the precise data that interests you. Afterall Blender is much faster than Pharo with dealing with 3d data and Pharo has light years of distance to cover before it competes in that area. By the way MORSE looks like it uses sockets already from what I read in the documentation section for communicating with matlab and other applications. I read also in the second link you sent "The last line configure the robotâs components on socket, for more information about services and datastreams, go to Middleware configuration <http://www.openrobots.org/morse/doc/latest/user/builder.html#middleware-conf...> " so if is fast enough for Blender I don't see why it won't be fast enough for Ephestos. Ephestos afterall is Blender and is Python. Its great that binding for Pharo already exist , I am sure you can find a way to make everything work together , including Ephestos. Afterall the biggest problem always is knowledge , " how I do this" , technology already provides huge amount of solution but you have to know how to use the tools. Ephestos wont teach you pharo, it wont teach you python and certainly wont teach you blender. My thinking about sockets is that they present two big advantages over wrapping code and FFIs a) Much easier to use. See how simple Ephestos is . b) No maintenance needed at all. The library changes ? no problemo, unlike a wrapper or a FFI no API needs to be defined at Pharo side, that ensures that the latest of the library ported is supported with no extra work. c) The socket bridge may have no scope, it could run as Ephestos does any kind of code and any kind of library out of the box. You sacrifice some performance but that a small price to pay over the advantages. On Mon, Jul 21, 2014 at 11:02 AM, Serge Stinckwich < serge.stinckwich@gmail.com> wrote:
On Mon, Jul 21, 2014 at 9:48 AM, kilon alios <kilon.alios@gmail.com> wrote:
Well in theory it should work.
I am saying "in theory" because I have not tried MORSE.
What is Ephestos ? Basically its a python application that creates a streamsocket server that listens byte data, then it takes the byte messages it converts them to strings and it executes them using exec() built-in python function. The end. See what I did here , I did not mention Blender at all. Actually Ephestos is implemented as Blender addon. So it gives you both access to Bpy and python libraries. A Blender addon is basically a python application + access to BPY + extra stuff to make it easy to select and enable in the Blender GUI.
Now from what I see at first glance MORSE uses BPY and BGE. BGE , the blender game engine is a separate app essentially with its own API. So I need to wrap Ephestos for BGE but it will still be the same thing with added more code to be called by BGE. It should be fairly easy to do and I will do it.
I don't know if there are other implementation details about MORSE but I don't think there will be a problem to make it work with Ephestos.
Of course Ephestos has still got some big limitations a) does not receive data from Blender b) does not support of multiline python code. I don't know about b) it may work already if you add newlines in your python strings and whitespaces but I will have to test this and of course improve it to make it easier to use. Both of these features will be added since they are high priority goals.
Thank you for your explanations Kilon. I understand better how it works now. Yes receiving data like perception data from robots is quite important for MORSE. One problem I envision, is that the data could be huge and some performance issues could appear I guess if you have to translate data structures from Python to Pharo.
BTW, Noury and Luc developed a ROS binding for Pharo. ROS is a robotic middleware that could be used to do communication with MORSE.
Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
I do have some great news I solved the problem with blender operators that means I now have full access to the whole API of blender. Everything in Blender API is basically operators and properties.There are still limitations to be solved of course. First that I will tackle is how to communicate data from Blender back to Pharo. Also I have added example code for people to look at. Just pull from my repo here http://www.smalltalkhub.com/#!/~kilon/Ephestos/ Ephestos is not something I am making for others to use, its primarily for my needs. Because I am very interested in interacting and integrating other Blender addons in my workflow I want to keep the Pharo API as close to BPY as possible. This will make it easy for me to port BPY code to pharo and talk to existing Blender addons. Blender addons are extremely important they implement tons of new functionality for Blender. A cube is not a separate object in BPY , a cube is basically a mesh object. So BPYMesh would make more sense. But in BPY its really a BPYObject. Additional I can be lazy and avoid documenting stuff since translating python calls to pharo is dead easy. Python has a very simple syntax, not as simple as Pharo but quite close. So its easy to go to Blender wiki BPY API and find all the information you want instead of me going through the pain of rewriting this huge documentation. There are also a lot of tutorials about making blender addons with python online, there is no way I can compete with that . So in the end if you really want to take advantage of Blender learning python and the blender api is mandatory. Pretty much every major 3d app uses Python and Python is a very popular language so there is nothing to lose by learning it. I would not put too much faith to me mapping alone the huge BPY API, the operators alone are 1500 or so I have been told, properties must be at least double that amount. Translating all that to Pharo objects is just an insane amount of work unless I find a cleaver way around it with some pharo parsing but still too much work for little gain. But I will map some basic stuff to decrease the need of writing python code. About Atlas here is the repo that I am going to post the code https://github.com/kilon/pyAtlas For now I work on Ephestos and when I am happy with the progress I made with it I will port it to Atlas and make an announcement here. Its basically the same code minus the Blender stuff. PS: It may also make some of you happy that I plan to expand Ephestos to include besides BPY also BGE. BGE stand for Blender Game Engine , its a game engine offered by Blender that excels at any kind of interacting graphics, that means that you will have access to a very powerful game engine and a general engine for 3d interactive applications. BGE is a lower priority , but it should be easy to implement once the big limitations of Ephestos have been solved. More info about BGE can be found here http://wiki.blender.org/index.php/Doc:2.6/Manual you can find finished games made with BGE here http://blenderartists.org/forum/forumdisplay.php?39-Finished-Games A very good example is this http://deadcyborg.com/ On Thu, Jul 17, 2014 at 8:31 PM, Hernán Morales Durand < hernan.morales@gmail.com> wrote:
2014-07-16 12:31 GMT-03:00 kilon alios <kilon.alios@gmail.com>:
yes the one I am considering as strong candidate is
(BPYObjects at: 'Cube' ) location : #( 0 0 0 )
Why not BPYCube?
I would try to simplify bpy ( Blender Python API) and make it a lot more pharo friendly.
However plain python string will be kept as well, so you can copy paste existing python code.
One thing to note here is that Blender python addons are a huge deal. Python addons are actually full blown python apps. Blender python is basically a regular cpython 3 which is by far the most popular python implementation , meaning not only that you can use blender api object but any python library you can find. As a pharo developer you also can tap into this power via Ephestos.
something that I forgot to mention in the video, in the github repo there is a rawcode.py. This is a strip down version of the Blender code that will separate to its own project that I am naming "Atlas".
The goal of Atlas, is to create a two way communication socket bridge between cpython (most popular python implementation) and pharo. Very similar to Ephestos but you will no longer need Blender. That means that pharo coders will be able to use python libraries from inside pharo and even mix python with pharo code. So you could make part of your application in python and part in pharo and still function as a single application.
I am interested in Atlas. Do you have a link?
If I find the time I would like to expand Atlas to other languages too, so that pharo can take advantage of any library written in any language without the trouble of FFIs. But most likely I will stick to python and let others do the work.
But even with just python as you imagine python is extremely popular and quite friendly with the pharo way of thinking. Meaning that in python its all about live objects too. Pharo will be able to tap into thousands of powerful python libraries. 
I reserve some doubts to the amount of problems I will have to face to accomplish this and I am no way claiming it wont be a long process but so far through these very first steps the idea seems to go well in practice.
On Wed, Jul 16, 2014 at 5:55 PM, Damien Cassou <damien.cassou@gmail.com> wrote:
On Tue, Jul 15, 2014 at 11:09 PM, kilon alios <kilon.alios@gmail.com> wrote:
The goal is to expose Blender coders to the power of Pharo and Pharo
to the
power of Blender. As you can imagine the potential is huge but I rather talk what Ephestos can do already.
That's great kilon! I can't wait to see how far you could go with that. I hope you plan to use Pharo syntax instead of plain string for the messages. A message like this:
"bpy.data.objects["Cube"].location = (0.0, 0.0, 0.0)"
could be written like that:
(EphestosMessage bpy data objects: 'Cube') location: (EphestosLocation x: 0 y: 0 z: 0)
or something similar
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
participants (9)
-
Ben Coman -
Damien Cassou -
Esteban A. Maringolo -
Hernán Morales Durand -
Jan Vrany -
kilon alios -
Sean P. DeNigris -
Sebastian Sastre -
Serge Stinckwich