- VobCoorder doesn't know which VobScene it is in, or which VobMap
it's using. This makes it impossible to implement this functionality
for OpenGL changing only GLVobCoorder, since the OpenGL state is
altered
by placing a new Vob in the VobMap.
I see three options, all of which aren't really nice.
1. VobCoorder is made to know its VobScene
2. VobCoorder.clip() is passed the VobScene
3. VobScene gets GraphicsAPI-specific subclasses
I don't really care, but I think 1) would be the least harmful (it make
some sense for the components to know the whole, I think, and the
potential for reuse of the components w/o reusing the whole is, for
practical purposes, nil). This could be implemented by a setVobScene()
method that'd be called by VobScene's constructor, and would throw an
exception if the VobScene were set already.
- How deep a stack is allowed / required? This makes a lot of difference
for the OpenGL implementation which has native stacks of fixed depth.
I dunno-- what size are OpenGL's stacks?
I would consider it solid design, though, not to put an arbitrary limit
on stack size and make this an internal issue, using OpenGL stacks as
long as possible and an own implementation otherwise. But it is ok to
defer this until later.
- Should clipping with this method work with nonlinear coordinate
systems?
This is a very fundamental issue for OpenGL, since if the answer is no,
we can use clip planes and get rid of much unwanted geometry, getting
better performance; otherwise, we need to use stencil and draw
everything.
I don't really understand the tradeoffs here. Hmm. I think that we do
need to be able to clip an area inside a nonlinear cs and then draw
inside that nonlinear cs; nonlinear cs would be much less useful if it
weren't possible to draw an ordinary cell in it, for example.
Again, it might be warranted to use one algorithm as long as no
nonlinear cs are involved, and a less efficient one otherwise (be sure
that both are tested).
- Benja