Moving data between Pharo and Blender via Ephestos is not a problem, just something I need to sit down and code. I can already access all operators and all propertied of blender from pharo via Ephestos. What that mean is that you can manipulate Blender from pharo any way you want.
Verse is a data protocol to move data around, it has some extra security but that is not relevant to Ephestos as currently my goal is local use. So both projects have very different goals. I dont also care supporting any other apps , right now , besides pharo and blender or having multiple users sharing data with each other. Saying that yes Ephestos can use Verse because it basically can use any python library so if you really want to integrate Verse into your workflow because you collaborate with multiple users using different applications you can use Verse's python api via Ephestos from Pharo. Verse is a C library with python wrappers. So there is not need for pharo wrappers if you use Ephestos. looks like the original author is still developing it --> http://verse.github.io/ On Sat, Sep 13, 2014 at 9:11 PM, Enrico Schwass <[email protected]> wrote: > Hi > > another option could be the verse protocol. There was a plugin for Maya > and Blender to do realtime rendering. Dont know if there is some automatic > Swig-like wrapper for smalltalk but FFI might work. > > http://youtu.be/c_D2YJSNj8I > > Almost a decade ago I did some ruby bindings by hand. It was working out > of the box > > Bye > Enno > > Am 13.09.2014 um 16:11 schrieb kilon alios <[email protected]>: > > > " I am curious. You mean rendering Bitmap from blender, for later use in > Pharo UI? " > > yes exactly. Blender can render in all popular graphics files, most used > are png. Animation frames can be rendered each frame in its own file. > > So basically its a lot like the average games out there. > > "I will suggest bare bone Morphic mainly, then Athens when you need > vectorial drawing." > > ok > > "For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap > source is SVG, then converted to PNG, overscaled for production use. Then > from iStoa, depending on the application window extent, the bitmap are > downscaled accordingly, I am pretty satisfied by the result." > > I fail to understand how your bitmap source is SVG for me bitmap is a > raster graphic format svg is procedural graphic format. Two opposite > things. > > "Sure. The downpoint, you will depend on one additional layer." > > dependency is not an issue. Afterall the graphic files themselves will be > far bigger download even more so if the GUI becomes very large. > > "Nice. What will be the expected outcomes of such API, I am not sure to > understand and I am curious." > > Well Blender besides creating 3d objects (which can be used as 2d objects > too) it can also create 3d unrendable objects. That means that objects > produce no graphics and have the role of placeholders or helpers, for > example when you want an emitter of light or emitter of a physical power > like gravity or wind. Those are called dummy objects and I could use them > to give characteristics to the graphics , for example I could use a dummy > to define the are of influence of a mouse click , or what type of event the > bitmap will respond to. That means you wont have to import the graphics > manually to pharo and create a separate morph for each bitmap and then set > the events but rather press a button in blender and then Ephestos will > import then bitmaps to pharo , set the events and create the morphs > automagically. > > So basically you will be using Blender as a GUI designer. > > "Use fuel to store the state of your application objects." > > ah nice so fuel is a good candidate. > > I will also take a look at Dr Geo and Phratch , both apps have custom GUIs > and use only Morphic (Dr Geo using Athens for the geometry primitives) . > >
