Jiba wrote:
Hum... it's a bit more complex in Soya, because the order in which
> the objects are rendered may not follow the scene tree.
You'd only have to rely on the OpenGL state in the display
list of a Shape. Then there are only two possibilities --
a given face specifies its own material
Jiba wrote:
However, i think the new deforming system (again :-) can be easily extended
to do that ; something like a MaterialSwitcherDeform. Instead of just
"one-material inheritance", i'm thinking rather to a dictionary mapping
old materials to the new ones, which would allow to change several
Jiba wrote:
> Someone else wrote:
> I have to make is that the UML diagram looks extremely blocky, at
> least on my machine.
It seems very depending of the program you use for viewing the PDF.
It looks nice for me in Preview on MacOSX, except
that the attribute descriptions are too wide for
Jiba a écrit :
Hi all,
The first RC for Soya 0.12 is available. Here is the Change Log:
* Massive renaming (backward compatibility is maintained through aliases):
Idler -> MainLoop
Shape -> Model
Cal3dShape -> AnimatedModel
Shapifier -> ModelBuilder
snaipperi a écrit :
On 7/8/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I think you should try to replace "terrain_drawColor" by "glColor4fv",
"terrain_disableColor" by "noop" and "terrain_enableColor" by "noop";
these
aliases were created for a workaround for a bug in some (linux) 3D
dri
Jiba a écrit :
I tried to compile your new sound api but iget an error. It seems 2
files have not been added/committed in svn repository : config.pyx and
config.pxd.
These 2 files are normally created by setup.py ; their content depend on the
configuration (e.g. sound support enabled or
> I suggest to make a category bitfield system as in ODE. Every object
> would have a 32 bit wide bitfield identifying witch categories it
> belong. The world.RaypickContext method would have an optional parameter
> telling witch categories it should care about.
>
> I also think it would be useful
> It seems like this should be fairly straightforward
> to implement, by making use of OpenGL's ability
> to push and pop various parts of its state.
> Whenever you encounter an object with a material,
> push the current state of the relevant OpenGL
> variables, set them up for the new material,
>
On Sat, 15 Jul 2006 09:20:30 +0100
Dunk Fordyce <[EMAIL PROTECTED]> wrote:
> i dont think you can use the same display list for a mirrored object unless
> you specifiy that the vert order for faces is also flipped when drawing a
> mirrored instance.
It is do-able with glFrontFace.
> i also thi
> Wow, looks great! I haven't actually tried going through it, and the only
> comment I have to make is that the UML diagram looks extremely blocky, at
> least on my machine.
It seems very depending of the program you use for viewing the PDF. The
original format is vectorial (EPS), so I don't
> Why limit it to 32? This is Python, we have
> long integers...
it's an ode limit
pgphgp3VT8gsD.pgp
Description: PGP signature
___
Soya-user mailing list
Soya-user@gna.org
https://mail.gna.org/listinfo/soya-user
11 matches
Mail list logo
