[Bf-committers] Re: Newbie coding advice.

[Greg MacDonald]

It would've been easier a month ago when I wasn't familiar with the Blender
code. I'm finding that even though some of the code is uncommented
spaghetti, its surprisingly not difficult make changes. Ton's architecture
overview helped out a lot.

I think I've decided to just change the code. The python solution sounds
like a kludge to me. Where as the c solution is sure to be just as elegent
for the user as Blender itself. So its not a question of what's easiest for
me, but what's easiest for people using it. I really would like the blender
openflight solution to be better than what people are currently using. Not
merely sufficient. Otherwise no one will be compelled to use blender at
work.

Thanks for your suggestion though. Any more would be welcomed. (I don't like
programming in a vacuume.)

-Greg

On 9/29/05, Nathan Letwory <jesterking at letwory.net> wrote:
>
> This sounds to me like you'd be easiest of creating n lights in a seperate
> .blend and then later on link to any of the lamp data you want. Just give
> the lamp data smart names, and you'll have your lighting palette.
>
> /Nathan
>
> > I never would've thought of that, that's a good idea. And I've already
> got
> > a
> > GUI written. But I just have one last wrinkle. Light points have a
> > sizeable
> > number of properties and a city can have thousands of them. Openflight
> > deals
> > with this by having light point appearance and animation palettes from
> > which
> > a light point can index into both at the same time. I was going to
> > duplicate
> > this in blender by creating palette objects that light point objects
> would
> > point to. I also have other non-heirarchical types to consider, like
> file
> > header information that would contain info like units, flat vs round
> > earth,
> > etc. I suppose I could just create an empty with attributes attached for
> > these as well. But that would create the possibility of two header
> > objects.
> >
> > Still I'm drawn to extending blender directly because I don't want the
> > user
> > to try and edit my mesh light point representations. Plus, I don't need
> > anything 3D to represent the light points, all I need is a glpoint. And
> I
> > can make the two header object problem go away in a much nicer fasion.
> >
> > I'm realy torn between coding in c so I get the effect I want and coding
> > in
> > Python where I'll be sure that my code will be widely accessible. No one
> > in
> > the Windows world is going to apply my patch and recompile. That's going
> > to
> > decrease the number of people who can benefit from my work
> significantly.
> > Especially since Creator, the program that spits out openflight, only
> runs
> > in Windows.
> >
> > I think the right thing to do would be to write a general plugin
> > architecture for Blender where everything is a plugin, including core
> > functionality. That way people like me wouldn't have a reason to mess
> with
> > the underlying code base because there wouldn't be any advantages to it.
> > It
> > would be slower but Blender isn't a runtime engine.. Oh, wait. It has
> one
> > of
> > those doen't it. :) I still think it could be good. For the game engine,
> > you
> > could have rendering plugins where people could insert the runtime that
> > their developing for and easily have a model viewer that would save them
> > the
> > time of loading their models into a seperate program. I would love to
> > contribute to such a project. Would be a huge undertaking though. Is
> > anyone
> > considering doing this? Because I can't be the only one with this idea.
> >
> > -Greg
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at projects.blender.org
> > http://projects.blender.org/mailman/listinfo/bf-committers
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.blender.org/pipermail/bf-committers/attachments/20050929/d5b83575/attachment.htm