Tech/LxEngine/Sandbox/Notes
From Athile
Contents |
2010
December
-- Arthur 11:03, 14 December 2010 (CST)
Thoughts on LxEngine...
LxEngine is still very much in the prototype stage. The definition of prototype here is "a platform to test out design ideas." In other words, the engine is not only not code complete, the design and goals of the engine are also still subject to change.
As a consequence, it's likely a good idea to occasionally write out what the goals and objectives look like at any given point in time. Here we go:
LxEngine should be a simulation and visualization programming environment. It should provide a highly flexible, intuitive data model that allows applications dealing primarily with 3D graphical data to work with that data. It should be highly dynamic and easy to plug-in new functionality. It should provide a pattern and general framework for specific functionality, without providing much of that specific functionality itself. The engine may include helpers and plug-ins for common functionality, but the core engine should remain an abstraction of a convenient data model for 3D graphics visualization and simulation.
What does the above mean?
- A DOM-like object model that supports easy serialization in and out
- Easy, flexible, lenient scripting APIs
- Direct support for common file formats
- System-independent, common services
- Intuitive data transport between subsystems
November
--Arthur 04:10, 16 November 2010 (CST)
Ideas -
- LxEngine would be more interesting if it pulled the sources for the various external components from their source repositories. Thus, changes could potentially be sent back to those projects to improve them.
- LxEngine would likely be used more if LxEngine were merely one component of - a sibling, rather than parent - in the directory structure. This way people who want to start a project would simply have access to various components.
--Arthur 06:51, 9 November 2010 (CST)
It may make sense to split the "core" LxEngine library.
- lxvar seems to be a useful library in its own right and the Engine/DOM is built on top of this, giving the library a clean place in the structure
- The Engine/DOM seems to have it's own 'space' as a framework, and thus might deserve it's own library
- Then there is a need for a large Lx utility library that contains 'everything else': point3, slot<>, stand-alone helper functions
However, I don't want build engineering to get in the way of or slow down development - therefore I'm resistant to commit to any of the above until it seems 'more' necessary.
--Arthur 05:17, 7 November 2010 (CST)
It should be possible to construct new materials directly via the API rather than via .material files.
--Arthur 12:16, 4 November 2010 (CDT)
Need to add Camera control, but I'm not sure I have a complete design in mind. I'm also distracted by the desire to add in nested procedural materials per the early OpenGL based LxEngine code. The problem is that how to add dynamically generated custom shaders to OGRE isn't all that straightforward: there's no way to implement a derived Material as far as I can tell, so the generator might have to wrap GLSL up in .material format. But even if that works, then likely any features like shadowing mapping which could be injected into the system "for free" will be lost on custom shaders. In other words, I don't see how to add a custom shader that "just works" with OGRE.
--Arthur 08:28, 2 November 2010 (CDT)
The View concept is going to require some thought regarding structuring. Attachments may need to be per Document-View and per Element-View. The current code has per Document and per Element components, but the View essentially becomes a multiplier on that. For example, it makes sense that the physics on an Element be 1:1 with that Element. However, if there are two Views of the same document - both using OGRE, but rendering in different styles, it is conceivable that there is data per-Document, per-Element, and per-Document-View, and per-Element-View.
October
--Arthur 10:49, 29 October 2010 (CDT)
View has a mix and match of "onAdded" callbacks and manually walking the Document when it is first connected to the View. This is inconsistent. The View needs the change notification to correctly handle dynamic updates to the Document, but the Document might exist before the View is connected to it - meaning it needs to walk the initial state that was set up before it registered for the change notification.
In general, View, Physics, and Javascript need to be refactored as proper Engine, Document, and Element Components.
--Arthur 05:20, 29 October 2010 (CDT)
Keep the core engine as small as possible. Let C++ plug-ins do the brunt of the hard work. Let as much of the application logic as possible be implemented via Javascript. Provide a concise, strong API via C++; provide convenient APIs via Javascript includes.
--Arthur 12:02, 25 October 2010 (CDT)
The engine runs via a series of discrete time slices known as "frames". The idea derives from the notion of one graphical frame per engine frame, but this does not have to be strictly true.
--Arthur 05:06, 21 October 2010 (CDT)
Re-iterating some project goals:
- Provide a DOM-like interface on a 3d scene
- Provide a CSS-like inheritance/class stylization scheme
- Provide a JQuery-like Javascript API for manipulating the scene
...then provide repository support (a set of related Documents)
- Provide with git-like revision control
- Provide access and security control
--Arthur 09:38, 20 October 2010 (CDT)
The Engine object needs to be the first object created and last destroyed of any (non-trivial) Lx objects. This creates a clean startup / shutdown start-point and end-point for integrity checking, initialization, and clean-up.
--Arthur 06:15, 18 October 2010 (CDT)
The Document is composed of Elements. The core "payload" of the Element is the value of the element. In HTML, the value is generally considered the inner HTML of the element - at the leaves, it is one or more TextNodes. In LxEngine, the value is a single Object. At run-time, this is any object deriving from the Object class. It likely would be a Mesh, a Light, or something of that sort. The Element itself is then used to structure the scene: add stylization classes, element Ids, and other DOM-like behaviors to the scene.
On disk, the Object is conceptually in a lxvar/JSON-like representation. This allows the Object to be accessed in a generic manner for generic scripts. However, it is more efficient to use the actual runtime class to avoid the translation between the native and conceptual representations.
