This project is read-only.


May 17, 2012 at 2:01 PM

The first release is up and working.

Some initial issues, and around 10% of the OpenGLES 2.0 interface is complete. The next main goal is to have models rendering to a viewport along with the main state manager system to be pushed into the framework and the test code removed.

In the next week, an ObjectManager will be added, with integrated OpenSteer.

All moving along nicely.

May 27, 2012 at 3:02 PM
Edited May 27, 2012 at 3:04 PM

Another week, and another release.

OpenGLES 2.0 interfaces is about 25% complete now - most of the annoying / difficult interfaces done (logging was the trickiest). Models are now being correctly loaded and rendered from the AssImp Model structure. This structure will be similar to the MeshRenderer structure in Unity3D components - the main difference being the user has access to a concept called layers which are "referential" association objects that allow a user to associate objects to be rendered with cameras and output layers (textures, screens, viewports / whatever - technically it could be anything).

The OpenSteer integration has begun. Currently I am toying with the idea of making most objects able to be dynamic, but I know from experience this is not how most scenes are represented - my problem is, that static components have been used in environments greatly because the hardware performance has traditionally been limited. The way I see it now is that most objects should be dynamic by default in case any interactivity decides to make them active? An example - vehicle driving along, hits a cliff/wall and traditionally that object would be a fixed object with some attached particles and maybe some 'canned' interactivity. However if the wall/cliff is made dynamic then the vehicle can 'damage' it and it can move given the appropriate changes to its structure. This isn't really physics, since the developer could 'respond' physically if they wanted to. The previous problem in the past is that they object itself, would have no way to move or break apart whereas I think this may make good sense as a default behavior these days. Will see.

Next week. More OpenSteer, More ObjectManager (its getting there), Some StateManager should be let loose and the Materials should make their first appearance.

So far.. so good. .. no blockers.. :)

May 29, 2012 at 3:11 PM

And so it continues....

OpenGLES is nearing 50% complete - and have managed to steer clear of using any unsafe code. So far, so good.

Models are being loaded in with their first texture layer - diffuse. Will work on material, alphas, and deferred rendering layout system. The intention with this renderer is to provide a 'flexible' pathway system that allows the use if fixed function setups (prebuilt glsl shaders that work 'out of the box') and mix in with peoples own shaders and render passes. This method will allow some unique possibilities:

- ability to render fullscreen post render style effects on specific objects only.

- ability to apply specific render passes to specific objects and cameras.

- the selection of how render output results are combined to build a final image. Dont like contrast or blur? then change the combine function :)

Various other niceties too..

By the end of the week the deferred rendering should be up and running. OpenSteer to be completed on the weekend, and thus most of the main framework complete by the end of the weekend (hopeful).

Moving on from there will be the integration of GWEN - possibly using xaml style UI generation hooked directly to it? (thanks Sergey for the idea :) ). Also more work to do on materials, layers and objects. Improve Mat and Vec libs. And much further down the track.. develop a nice UI to generate scenes, and so forth. Integration with yEd is something I wish to play with (Visual programming construction tools).

Things still ticking along well.. time to visit GARY. :)

Jun 4, 2012 at 3:20 PM

Material, Shader and RenderLayer near completion. Cameras and Texture outputs still yet to be properly completed. The aim is to have an easily modifiable Render Layer system. A basic Shader editor and viewer is already partially complete (see screenshot). This will be integrated into the Render Layer diagram builder.

Multi-Channel output now supported. Can drive as many visual outputs as needed with individual Window control (embedded or not).

GWEN and GUI building is next on the agenda once Render Layers are complete. This will provide the base deferred rendering passes that will allow the user to dfine their own combination of layers and how combine operations will be applied.

Not enough time.. need more time :)

Jun 11, 2012 at 5:35 PM

Render Layer Window has be started. This will help define the Render Layer control - this is how the deferred rendering process will/can be controlled by the developer using simple visual tools. Need to finish off the visual components, and then serialize the RenderLayer information. Overall its looking very good so far, hopefully the RenderLayer Window work should complete during this week. This should also result in completion of the material layout and some design docs to go up here as well.

Hopefully will get into GWEN implementation next week.

Should be able to soon make some simple demos to see how this all binds together as a single application.

Need more time...

Jul 14, 2012 at 7:17 AM

Ok.. have had a little break. Working on RenderLayer, Materials and Camera layers. 

Should have a new check in over the next day or so... time... flys by so damn fast...

Nov 11, 2012 at 5:49 AM

Hoorah. The big change is done (in its majority, there are still small portions to complete).

I am really happy overall with the result. Cairo is a brilliant toolkit for GUI elements and I really hope to extend this system to become a fully feature complete GUI toolkit. At the moment it has a few nice widgets and that is about it. I can now focus back on the couple of titles I am really keen to get out as completed titles - xmas is looking unlikely but maybe a little xmas tetris will do instead :)

Cant believe how long this has taken. Looking forward to pushing some applications up on the store.

Dec 1, 2012 at 12:03 AM

More changes:

- Updated Sky object system to support three types of sky rendering.

SkyBox - traditional skybox with cubemap type texture 

SkyDomeTexture - Much like skybox, only it uses a skydome and a cubemap texture. This is better if you want more 'radius' based sky dome (clipping / fogging)

SkyShader - this is a fairly computationally heavy cloud/sky renderer onto a skydome. It still needs some tweaking (projection is a bit silly looking, and horizontal panning not working). But this shader will be optimized in the future and will contain a number of capabilities (scattering, etc).

- Various improvements to Cairo GUI, more button improvements.

- Improved Cube, SphereCube generator.

Planned coming changes:

- Asset viewer (examines project folder and registers known assets)

- Asset interface (behind the scenes API for all asset loading / management)

- Project config panel

- Assimp lib restoration. This will only work with WSE - when an asset is loaded, it will be converted to an internal format and that gets deployed. The main goal with asset importing is to allow wide use of incoming asset types, but converted for deployment to platforms (thus easier to manage multi-platform use).

Many panels and interfaces to come. 

Dec 3, 2012 at 10:44 AM

Added Assimp Library. 

Still need to complete asset management to make textures, meshes and other assets.

Dec 17, 2012 at 11:42 PM

AssetManager now nearly completion as a framework - still a number of filter type previews to do. 

Next steps:

- Project configuration and setup panels

- Completion of the Assimp library.

- Cleanup of the main framework structure to execute a game state.

- Build Panel for target platforms. Intended output: x86, x64, OSX, IOS, Android and Win8 RT. Initial platforms x86, x64 and Android (others will come later)

Lots to do in the general GUI system as well. Will need some cleanup of widgets.

Dec 21, 2012 at 2:44 PM

More updates. Added a more central "main startup" screen that provides a proper entry point to a developer's work flow.

The main elelments are:

- Create / Modify / Save - This will take the user into the previous WSE with a number of editing features and facilities.

- Play - The aim of play is to allow a developer to examine the execution of the application without all the editor distractions. Additionally the "Play" will include elements like profiling, debugging, and asset tracking.

- Configure - The configure button name is likely to change to "Build". It includes all the platform and target configuration for building a package to deploy. Additionally all the editor configuration is available here. 

- About - Simple info about the people involved in byt3d and other useless bits :)

- Help - The idea of help is to provide a multi-tiered approach to assistance for byt3d. The base level (tier 1) is html & pdf organised documentation. The documentation will follow the standard set by AutoIT (imho one of the best documented development systems around) where all commands and extensions have practical examples in the documentation that when cut-and-paste, work straight away. This is a pretty large task and will take some time. Tier 2 help will be targeted at forum and community assistance with hyperlinks to commonly tagged problems. Tier 3 will be personal support that will be service oriented and must be paid for (details to be worked out when byt3d reaches a mature release).

- Example Scene - A real embedded example scene with _all_ samples of commands and features included. Currently the goal is to use a VLE training scenario as the basis for such an example. The VLE (Virtual Learning Environment) will show off the ease of use, and high level development ideas that byt3d is being developed by.

- Tutorials - The tutorials are an extension to the Help, but they represent real scenes, with playback sample tutorials of all the features and how to implement and use them. Tutorials will likely be limited to begin with (covering the main elements) but we hope to have a complete set by the time byt3d reaches maturity (Release 1.0). 

Lots.. and lots to do. There is at least 6 months of work left to get the main elements complete. And probably another 2-3 months of testing and documentation. The testing framework is being looked at right now, and the aim is to have luaTestMore tests being integrated from the start of next year onwards. 

Overall, its getting exciting and 'real'. A number of large components are working very well and extending nicely (Cairo especially). The design will be updated again in the next week or so to capture the movement of the framework. Additionally a 'task list' will be put up so people can see progress and expected targets.