[fluxus] rendering 4D (newbie questions)

[dave]

hi claude :)

> > I tried that, but it seems that the (build-cube) primitive has more  
> > than 8 vertices, confusingly.  And my attempts with (build- 
> > polygons) failed horribly, I even managed to make fluxus segfault a  
> > few times with my broken code.
> 
> oh, yeah, it must be the same thing as with the sphere - fluxus  
> doesn't use indexed vertices, but they repeat for each polygon, so  
> that you have 24 vertixes which are in facts 8 triplicates ;-)
> 
> this is just a wild guess, since i haven't been deforming cubes yet.

this is correct, the cube consists of 6 quads with 4 verts each, so
there is a lot of duplication. as in the case of the sphere, this sounds
sub-optimal, but it means the entire array of data can be sent to opengl
in one call, making it much faster than individually indexing through
verts.

> >>> 4)  I noticed an (opacity n) function - does this work in terms of
> >>> solids (so you see less and less the thicker the object is) or  
> >>> in  terms
> >>> of surfaces?

everything is surfaces only, opacity is just a blend amount for drawing
the rasterised pixels of the polygons to the screen, over the top of
what was there previously

> > Each of the 8 subcubes is rendered in 1 bit of the 8 bit pixel, and  
> > the palette is calculated so the overlap of the polygons in each  
> > bit of each pixel shows an average of the colours assigned to each  
> > subcube.
> 
> something like that is possible with opengl, but may be tricky to get  
> right with fluxus as it is now.

hmm, I think blendmodes and textures will the way to do this kind of
thing, but I am not sure what you are after exactly. 

using opengl is a different approach to a software renderer, less
flexible (although this is arguable now with programmable shaders) but
very fast, and quite flexible if you take time to get the idea behind
some of the restrictions. for instance regarding the opacity problem,
there aren't many games out there that don't have this bug in them in
one form or another.

and as for 4d stuff, my approach would be to implement them as a scheme
library, and see if that is fast enough. I'm not too sure what it
involves, but I guess you'll need to do your own projection from 4d
world -> 2d screen + perspective. 

cheers,

dave