Concepts for the new Icarus Design Studio

Jul 21, 2011 at 7:08 AM

Here are some of the key areas of research going on for Icarus Design Studio, the replacement for Icarus Professional in Icarus Scene Engine 3.0.


These bullet points are from the point of view of a Developer looking to integrate.


Designing Objects

There will be a separate class structure from the SceneObjects, the SceneObjects themselves will be responsible for the direct rendering, the designer will now be more than capable of extracting and making wireframe versions because everything uses a common buffer array.

How it will work is a generic class, DesignerObject<T>   where T is an AbstractSceneObject, this provides “default” behaviour, default editing, default design time rendering capability, default design movement etc... then if you want to add new behaviour or different behaviour, create a specific descendent class named after the type you want to create, i.e. DesignerSceneLight, DesignerSceneCamera etc.. and that’ll then handle things differently for the different object type.

 This will help keep design time coding and functions separate from runtime, so, for example, if you are making a robotics plugin called XBF, you can have an XBF.Motors.dll and an XBF.Motors.Designer.dll, then it’s also easy to cut one from the other and distribute without enabling reverse engineering.


Custom Lists and auto-saving to XML

 A class called SceneTree<T> is provided, it’s just a simple override to List<>, but it’s implication is that it’s for additional custom Scene object types, and it represents a hierarchy to drill into, so that the list auto-saves and loads to and from XML. 

Property Editing

 Additionally a second class, DesignerUI<Class, Mode> will represent a default property editor for a class, for a given mode. i.e. modes will represent high level editing states, like Movement, Dimensions, Text, etc.. and you’ll be able to specify new Modes to edit in custom forms for specific properties, there will be a bunch of default UI types that will auto-add to a Storyboard, and then u can move them around from there. The idea here is not to present the user with a big long list of overwhelming options, but to focus in on the current “Mode”, which will be togglable like a Tab bar, or a Toolbar list of icons.

Adding Objects to Scenes.

 In reference to the Mode section above, one additional Mode per-object will be to “Add”. The Add tab will then show a list of common objects to be able to add. There will be a standard library as well to be able to add things, that will come up in a popup with Preview, but really there should be a whole bunch of templates set up with the root object for each type already picked out, so that the Add can focus in on what’s needed. i.e. you would have a Template file for RobotKit, RobotKit then lists all the classes suitable to add to it, so that they can quickly get to the relevant portions of the system.


 Nothing will really change much visually with the Animation, except being more integrated, and this time with an “auto-key” function.

 The Flowgram

 With the new Levels concept in ISE 3.0, all levels can just preview like a hierarchical Powerpoint, kind of like where I was going in ISE 2.0, with the white bar on the left with the square scene previews. with different background colours, or a very slight indentation. All objects in the level are now completely non-hierarchical by default, so that makes it much easier to just slap things into the scenes, select from the toolbox and then draw. i.e. unless you’re doing logic, linking bits together, there’s no need for a full flowgram.

 Instead, objects with Custom Trees in them (like the SceneList<T> class mentioned above) show only their portion of the Flowgram when clicked on. This can then be “pinned”, so that they can go click something else, or just Shift-click to select something else, then the user gets two mini-flowgrams side by side that they can join together. An additional “Logic” mode then shows all the individual links in the 3D space. Objects that don’t have a 3D presence will be given one for the Logic view, so that the logic gates can be moved around.


 The old IPX embedding will just go. It added too much complexity without really solving the problem of what was actually needed, actual classes. Instead, developers may reference additional Designer DLL’s in the IPX to load already-compiled functionality. Below in the XML is an example.

 Instead, to create an embedded class, now Save As Template… and it will generate the class, compile and then added to the Library




<XML format blah blah header info here>

   <prj name = >

   <as>                                         - Assets

       <tx></tx>                       - Textures

       <ft></ft>                         - Fonts

       <mt></mt>                     - Materials

       <gm></gm>                     - Geometry

       <sk></sk>                       - Skeletal Animation


<ref dll=”{PLUGIN}/XBF.Motors.dll” ver=””/>                           - The new way to do Embedding. Specify the DLL, and if it’s not found, fetch it from the web. How that’ll work is it’ll ask for a registered source for a DLL, and then route from there.

<ref dll=”{PLUGIN}/XBF.Sensors.dll” />                                             - This one doesn’t care for the version of the DLL.

<pnl>                   // Represents the Panel (can’t be more than one)

                 <scene name=”Scene 1” enabled=”Y” locked=”Y”>                  

                                     <robot name=”Dandy”>

                                              <serial333 name=”CPU”>

                                                           <SOLsensors>                 - Added because it’s a custom list, part of the class. Only lists will expand down. The SOL is added to the front to avoid tag naming repetition.

                                                                         <sensor ……