Re: [Glelite-deve] Re: Things to do

[Kalle A. Sandstr\o. <ksa...@ik...>]

On Tue, Apr 24, 2001 at 11:58:32AM +0300, tsuoranta wrote:
>=20
> > I tried checking the 'Teddy' module out but sourceforge seemed to have
>=20
> Any luck now later?

I'll try later today.

> > Now, I'm sure that this is too early to start thinking about performance
> > (the rest of you seem to be in feature mode anyhow ;-), but it might be
>=20
> No, it certainly is important to get performance working well. Thats why
> I reworked material management and as result there Projection between
> ModelInstance/Mesh/Element drawing and View (OpenGL&Graphics context).
> It is still missing vertex buffer.

Perhaps we should also prepare for the (IMO) inevitable addition of
graphics-card side vertex buffers by providing a kind of abstraction for it.
Nvidia, at least, seem to have their own extension for this.

(i.e. the idea is that the driver wouldn't need to copy vertex data from
client side into the card's AGP buffers on every frame drawn; this could be
a big win for static objects)

> > worthwhile to explore other landscape rendering algorithms besides ROAM
> > (which is commonly said to be too CPU-intensive to peg a modern T&L car=
d).
>=20
> Again, the version of ROAM currently included is a really badly broken.
> The newer code uses vertex arrays etc., but it will mean some work before
> I can integrate that into current code. Anyone willing to do the
> integration?)
=20
I have other projects currently (heh, about 3 or 4 of them ;-) so I can't
really do much else than maybe give almost constructive criticism on
the design...  Maybe when I have more time I'll do something about the
physics engine.

> > Ideally, the not-ROAM landscape algorithm would produce results that lo=
oked
> > about the same as with ROAM, but consume less CPU time per vertex while
> > possibly generating more vertexes.  Having a second algorithm would also
>=20
> It is possibly to tweak ROAM a lot. Currently there is a lot of slowdown
> caused by the multifractal, which is really calculated in real time. It
> would be a much better idea to cache fractal values somehow. Also you can
> combine different fractal (or other height functions!); plasma for some
> parts could be a lot faster. Also I am not happy with the currently
> generated terrain. It is missing features, or something..

You mean it looks like a badly cut block of moldy cheese?-) No offense,
of course...

> What I did not tell it the previous mail (about rendering architecture)
> was that I wan't to support rendering preferences *per Projection* in
> addition to per ModelInstance. This means that I can tell Projection that
> 'Now use flat shading, no textures' or 'Now use monochorome, wirefrane
> rendering with hiddenline removal' and that will apply to all objects.
> You can already turn lighting on and off in the Teddy 1.37. Also see
> UIobjects.cpp for material / rendering options per ModelInstance.
>=20

One thing that I learned while writing one of my failed prototype 3d
engines was that you can't really keep material handling separate from
geometry handling. At the very least, for multitexturing (primitive per-pix=
el
point lights, that sort of thing), you'd need some kind of an interface for
the geometry to draw itself multiple times in a certain order, etc...

Perhaps a kind of Visitor pattern would be useful here, like wotsisname
(sorry, can't remember) said - that would remove some code redundancy from
the Renderable (I'm assuming that you still have Renderables; I haven't
looked at the code in ages...) implementations.

> Networking is tighly coupled to the physics simulation (that is what
> I call anything that 'happens' in the game). So far I have only worked
> on the rendering engine. There exists a very very primitive physics
> simulation, but I have no plans to improve it much in the near future.
>=20
> It is true that networking affects a lot of design for physics simulation.
> Thus we should encapsulate the whole physics simulation as much as
> possible from rest of the game. This is how it is possible to make
> framework that works for both networked and non-networked games.

Perhaps a good design would be to keep the "what happen ?" code
separate from the "main screen turn on" stuff, so that if the game were
run without networking the server object (or some such) would run on the
local computer in a separate POSIX thread.

> > http ohutsuoli 2*viilto www piste iki piste fi viilto mato ksandstr vii=
lto
>=20
> ^ ..not very international.. ^

It's not intended as such :-)

--=20
Kalle A. Sandstro"m                             ksandstr &at& iki &dot& fi
http ohutsuoli 2*viilto www piste iki piste fi viilto mato ksandstr viilto
1ED7 C636:              7728 49D5 F784 D2DD D20F  63CF 655D F19E 1ED7 C636