Re: [pygame] GSoC Easy simple software 3d

[René Dudfield <renesd@xxxxxxxxx>]

Hi,

your application looks pretty good.

+1 for obj rather than 3ds.  Obj has more wide spread editor support.
However, it sounds like you have written a 3ds loader/renderer already
- so that knowledge will be useful.

I'd note in the title it will be opengl based, since then you will
likely get more support from the non-pygame people too.

Also, unittests will be required, so please mention them in your
outline.  It's good for the tests to be written as you go, rather than
at the end.


cheers,



On Tue, Mar 31, 2009 at 6:25 AM, Marcus von Appen <mva@xxxxxxxxxxxx> wrote:
> On, Mon Mar 30, 2009, Kurucsai Istvan wrote:
>
> [...]
>
>> About My Project
>>
>>     1. My project is about implementing "Easy Simple Software 3D" support for
>>     pygame. It would be capable of loading and rendering 3D models and handling
>>     basic OpenGL functionality like lighting. I divided the task into 3
>>     subprojects:
>>
>>         I. Choosing/wrapping an appropriate software OpenGL implementation.
>>             There are several candidates for this (tinygl, sdl-tinygl, vincent).
>>             The chosen implementation has to be fast, reasonably bug-free and
>>             appropriately licensed.
>>
>>         II. Choosing a model format and developing a loader for it.
>>             3ds and obj are the most likely to be used. Both of them has plenty
>>             of documentation/example code, obj is simpler but I already have
>>             some experience with 3ds.
>
> I'd recommend to focus on the obj format here. It's even more common
> than 3ds and most modelers support export/import facilities for it. If
> you have enough time at your hands later on, you can go ahead and add
> 3ds support or whatever else, so you should add an optional task about
> adding more loaders.
>
>>         III. Writing the engine.
>>             The main goal is to make the interface of the engine as simple as
>>             possible while retaining functionality. Loading and displaying a
>>             model should be as simple as 2 function calls.
>
> The internals of the engine should be nicely layered (using as less
> complexity as possible to keep it fast), so it can be exchanged easily
> with another software engine or even hardware bindings.
>
> Besides that, your proposal looks all good to me.
>
> Regards
> Marcus
>