[fluxus] rendering 4D (newbie questions)

[Artem Baguinski]

On 26 Feb 2006, at 04:20, Claude Heiland-Allen wrote:

> I think I found a bug:
>
> From the manual:
> "(mouse-button b) returns true if the corresponding mouse button  
> has been pressed this frame."
>
> In fluxus-0.8, (mouse-button b) seems to ignore the value of b, and  
> returns non-0 on mouse-up and 0 on mouse-down.  See the attached  
> script  - an attempt at making a two-player 3D tic-tac-toe game.   
> The intention is that left button makes balls green, and right  
> button makes balls red, but it doesn't work - both buttons have the  
> same effect, and it's only button-press and button-release that  
> change anything.
>

you should report it at bug tracker: https://savannah.nongnu.org/ 
bugs/?group=fluxus

otherwise we may forget ;-)

>> using lists would be wrong indeed. vectors are more efficient.
>
> Ok.  Is there a Scheme manual online somewhere that documents all  
> the functions?
>

fluxus is based on guile 1.6.7, it's manual:

http://www.gnu.org/software/guile/docs/docs-1.6/guile-ref/index.html

>>> 3)  How would I go about constructing a (distorted) cube, given 8
>>> 3-vectors for the vertices?  From my brief reading, I guess I  
>>> would  use
>>> (build-cube) and (pdata-set ...) to move the vertices - is this  
>>> on the
>>> right track?
>> sounds right.
>
> 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.
>
>>> 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?
>> i had a look at your pages but i still don't get what you mean by   
>> solid rendring. the screenshot you've got there is doable with a   
>> bunch of poligons no?
>
> This animated gif is what I had in mind by "solid", if that makes  
> anything clearer:
>
> http://claudiusmaximus.goto10.org/files/coding/hypercube/ 
> hypercube-0.3.9.gif
>

i can't get to your site atm :-/

> 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.

>> opacity just sets the opacity of the paint you're using. with  
>> opnengl  you mostly draw points, lines and polygons, so it's their  
>> paint  opacity that you can control.
>
> Ah, I understand now.  But, I think I found a bug with opacity,  
> probably down to something other than fluxus itself:  depending on  
> how you rotate the view, sometimes the opacity jumps to 1 instead  
> of the value I set it to.  Compare these two screen grabs, all I  
> did between them was rotate the view slightly:
> http://claudiusmaximus.goto10.org/files/temp/fluxus/sphere-opacity- 
> bug/sphere-opacity-bug-1.jpg
> http://claudiusmaximus.goto10.org/files/temp/fluxus/sphere-opacity- 
> bug/sphere-opacity-bug-2.jpg
>
> Are objects only transparent in one direction?

that's because fluxus always renders the primitives in the same order  
+ uses depth testing.

explanation:

depth testing is useful when rendering opaque primitives: each time  
opengl renders something into framebuffer it also stores the  
"depth" (sort of distance from the camera) of the fragment in a  
special buffer. if the new fragment to be rendered has higher depth  
value then is in the depth buffer (i.e. is further from camera,  
"behind" the object already rendered) it won't be considered to save  
some time.

but with translucent objects that breaks the effect: if fluxus has  
rendered the closer translucent objects first depth test makes him  
skip the objects behind.

usually this problem is addressed in opengl based rendering systems  
by dynamic reordering of opaque and translucent objects. fluxus  
doesn't do that, hence the problem you're seeing.

somewhat simpler (but wrong, but could be acceptable) solution is to  
disable writing to depth buffer when rendering translucent objects.  
not sure you can do that with fluxus atm, but this is easier to add  
then the "correct" solution.

There is actually no universal correct solution, the most visually  
correct one involves detection and splitting intersecting polygons  
and then reordering them, but implementing it would be very slow.