[racket] Crowdsourcing Pict3D's design

From: Alexander D. Knauth (alexander at knauth.org)
Date: Sun Mar 15 16:54:39 EDT 2015

On Mar 14, 2015, at 11:51 PM, Neil Toronto <neil.toronto at gmail.com> wrote:

> What you need is to 1) create and combine the necessary Pict3Ds as much as possible before the game starts; and 2) reuse them as much as possible during the game.
> 
> You can even make the reused Pict3Ds fairly large if you freeze them. Any modern 3D card won't have any problem with this, for example:
> 
>  (freeze (combine (get-tube+obstacles (make-world-stream) +x 1000)))
> 
> Freezing takes a while, though, and has this annoying property that it takes the most time the first time the frozen Pict3D is rendered. (The actual freezing has to be done with an active OpenGL context.) I'm not sure what to do about the latter problem.

If I made it a finite game, with a finite tube, I could probably generate the whole tube once and move the camera along it, but with an infinite lazy tube, I’m not sure how I can reuse it.  

> If you don't mind, I have a couple of questions.
> 
> 1. What was the most annoying surprise?

The most annoying surprise.  Before you gave me your parametric-cylinder function, I tried approximating it with a bunch of normal cylinders.
I created them upright, in position, and then rotated them, but I hadn’t realized that when it rotated them it also rotated their positions around the origin, so they weren’t showing up.  Then I created them upright at the origin, then rotated them, and then used move to put them in place.  The current behavior does make sense, but a note in the docs might be helpful.  

> 2. What was the most pleasant one?

The most pleasant surprise was your parametric-cylinder function, and that it allowed me to supply the derivative, which was exactly what I needed to make the ends of the cylinders line up.




Posted on the users mailing list.