Re: [Wing-007-technical] Wing v1.0 Planning Discussion

[Stein G. G. <gra...@pv...>]

Stein Gunnar Grastveit wrote:
> ??? wrote:
>> Hi Asim,
>> Please see my comments below:
>> 1. Concept definition, preparation and documents.
>> 1.1 What is WingSDK? What's the principle to expose some stuffs to SDK?
>> 1.2 Separate wing developers and SDK users. Provide forums, defect 
>> management page, maillist for developers separately.
>> 1.3 Wiki (Include end-user wiki, SDK user wiki and developer wiki).
>> 1.4 Patch system, so that everyone can submit their changes safely 
>> and easily.
>> 1.5 A specification of detailed coding standard, module design 
>> principle, directory, development cycle that is agreed by every 
>> member of wing.
>> [Asim] My assumption is that landscape editor will be built on top of 
>> Wing SDK. This landscape editor will help us decide which methods of 
>> SDK should be exposed. Agree with all points above. I think we 
>> already hav 1.5 in place.
>> [Qilin]: Yes, landscape editor will be built on top of Wing SDK. I 
>> agree with you.
>> We don't have 1.5 in place. Because I want every member review 
>> existing coding standard and add their comments.
>> 2. Platform independent build environment
>> 2.1 Consider using premake to create the *.vcproj or makefile: 
>> http://premake.sourceforge.net/
>> 2.2 Define a rule where do we put premake scripts, makefile, vcproj 
>> and intermidiate files.
>
>> 3. Platform independent code base
>> We need a platform-independent code base because: a) A lot of 
>> developers are working under linux, we don't want to lose them; b) We 
>> have worldwide team and we want to lower the difficulty of data 
>> transmission between two modules that are written by two different 
>> developers. c) Everyone can learn the code base easily and contribute 
>> to the same code base, so we can reuse the code as much as possible 
>> and can avoid wasting time on inventing a same wheel.
>> 3.1 Assert, Log, Error and Exception. #include <Wing/Debug.h>. I want 
>> to make the file name and position simple because the file name and 
>> position is also a part of a SDK. Any change to the file name or 
>> positions will make other developers to learn the change.
>> 3.2 Thread, Signal and Mutex. #include <Wing/Thread.h>
>> 3.3 Process, Dll or Module. #include <Wing/Module.h>
>> 3.4 Memory new & delete. #include <Wing/Memory.h>
>> 3.5 Math structures and algorithms. #include <Wing/Math.h>
>> 3.6 String functions and classes. #include <Wing/String.h>
>> 3.7 File, Directory, Disk. #include <Wing/FileSystem.h>
>> 3.8 Time. #include <Wing/Time.h>
>> 3.9 Unit test framework
>> 3.10 Class factory.
>> [Asim] This is a difficult problem to solve. I am afraid there will 
>> be some components which will be platform specific. The challange 
>> will be to keep those to minimum. I would love to use STL but you 
>> have already noticed some issues in DLLs. Questions for Linux 
>> developers...are there any STL issues on Linux?
>> [Qilin]: If we have to use OS-specific functions (eg. 
>> CriticalSection), we need to provide an unique interface and 
>> implement in different ways under different platform.
>> 4. Documents for code base so that every developer can easily 
>> understand each part of the framework.
>> 4.1 Each function, macro or class that is exposed to SDK will have 
>> clear comments and we can generate *.chm help file from those comments.
>> 4.2 Each module will have a unit test.
>> 4.3 We have samples and tutorials. They don't need to be very 
>> complex. Just simple tutorial and example will be fine.
>> [Asim] Agreed. *.chm files are nice but will they work on linux? How 
>> about doing something like 
>> http://www.ogre3d.org/docs/api/html/classOgre_1_1Mesh.html? I noticed 
>> that OGRE is using std::vector.... it seems there are some stl 
>> components which are cross platform unless OGRE is doing something 
>> different for dll.
>> [Qilin]: *.chm doesn't work on linux. Therefore we have to provide 
>> html format for linux users. An online documentation will be useful. 
>> That's a good idea.
>> Ogre uses stl directly in its header files, and Ogre has many 
>> problems which I will mention below.
>> 5. Render engine selection and render bridge design.
>> There are many 3D real-time rendering framework: Ogre (used by many 
>> open-source games and editors), Irrlicht (famous too), Open Scene 
>> Graph (Used by Virtual Terrain Project), etc. However, for wing, we 
>> have the following requirements:
>> a) The rendering framework should be platform-independent.
>> b) We need a virtual device system so that we don't care 3D API 
>> details (Direct3D 9? Direct3D 10 or OpenGL).
>> c) We need a mature material system so that we can customize 
>> platform-independent materials and shaders in memory.
>> d) We need a mature resource cache so that we can define video 
>> resource management strategy easily.
>> e) The render framework should not add any restriction to wing. We 
>> should be able to render any customized 3D objects easily.
>> f) We need be able to define our own LOD strategy for grasses, tree 
>> leaves, water, terrain, etc.
>> g) To be determined...
>> [Asim] Does OGRE statisfy requirements a-f above? I am not familiar 
>> with any of the engines listed above. But, we need to decide quickly 
>> which rendering engine to use. I can do some research on OGRE and 
>> someone else can research on one of the other rendering engines. We 
>> can then report back the results. Or we can just make a decision and 
>> pick one framework without research. We also need to work on bridge 
>> design. I quickly looked at TriMesh impelementation in Wing. Does it 
>> support rendering? or is there a plan to build 'bridge to rendering 
>> engine'?
>> [Qilin]: I wrote a "birdge" by using Ogre. Please see the attached 
>> code. You can see the only interface for a renderer is 
>> Include/IOgreRenderer.h. It is very simple. I designed that interface 
>> because I don't want our data model knows the detail of a renderer, 
>> therefore we can use different renderer (even software renderer) to 
>> render our scene.
>> Based on my evaluation of Ogre, it is good and its functionalities 
>> satisfy our requirements. However, Ogre has the following limitations:
>> Ogre_1. Too many templates and STL in header files. Those looks cool 
>> however the consequenses are: compilation extremly slow, adding or 
>> removing a breakpoint may takes seconds.
>> Ogre_2. Too many inline implementations in header file, even for 
>> virtual functions. Consequenses: When building the 3MB source code, 
>> 1.75GB intermidiate file, 800MB libraries and 20MB dynamic linked 
>> library will be generated.
>> Ogre_3. It is called to be "Object Oriented" but it follows OOP just 
>> in a very high level. You can see very huge classes everywhere in Ogre.
>> Ogre_4. Too many hard code in OgreMain for shadow, which makes the 
>> code difficult to modify and maintain.
>> Ogre_5. No shader fragment management.
>> Recently, I'm looking at Open Scene Graph, which provides an OpenGL 
>> similar interface. It looks more suitable for us than Ogre. I will 
>> spend some time on it and see if we can use it.
>> 6. Editor UI middleware selection and parameter-UI-script binding.
>> The most famous UI middleware: wxWidget, Qt.
>> Scripts: lua, phython.
>> Our requirements: To be determined...
>> [Asim] The tools listed above are well known. I think we should go 
>> with the tools we are comfortable with or have previous expierence. I 
>> have no preference.
>> [Qilin]: I prefer wxWidget, it is free under all platforms. For Qt, 
>> it is not free under windows.
>> For script, I have 2 years experience on lua and I have wrote lua 
>> script binding modules. The good side of lua is it is very simple to 
>> use and light weighted, however the down side of lua is that there 
>> isn't too much functionalities.
>> phython is powerful, and have many extensions and functionalities. It 
>> is called "object oriented script" but it is much heavy than lua.
>> [steini] The question is what are the script support to handle? If it 
>> is just small asjustments done by a user, I think LUA is useable. But 
>> if it is for development scripting, maby
> we need python.
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------ 
>>
>> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
>> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
>> easily build your RIAs with Flex Builder, the Eclipse(TM)based 
>> development
>> software that enables intelligent coding and step-through debugging.
>> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Wing-007-technical mailing list
>> Win...@li...
>> https://lists.sourceforge.net/lists/listinfo/wing-007-technical
>>   
>
>