On 03/14/2015 10:27 PM, Alexander D. Knauth wrote:
On Mar 8, 2015, at 10:53 PM, Neil Toronto <neil.toro...@gmail.com> wrote:
If you've ever had the slightest hankering to do some real 3D but avoided it
because of the pain that usually goes with it, try Pict3D. (If it fails to
work, please submit a bug report on the GitHub page.) Got a visualization
project? Try Pict3D. Want to make a game? Try Pict3D's version of Big Bang.
Want to just fool around in 3D space for a bit? Try Pict3D, and report back on
how it goes.
I made a version of the game unpossible using pict3d:
https://github.com/AlexKnauth/my-unpossible
It’s a bit slow and jerky, but that’s probably entirely because I didn’t try
too hard to make my end of it fast.
If you have any suggestions that would be great.
Very cool!
Let's be fair to you: it's not obvious how to make it fast. I'd love to
make the API so that it *is* obvious, or so that the techniques to make
it fast are done automatically.
Here's an indication about what's going on. Try these in the REPL:
(time (void (get-tube+obstacles (make-world-stream) +x 40)))
(time (void (combine (get-tube+obstacles (make-world-stream) +x 40))))
(Using `void` just keeps the Pict3Ds from getting rendered.) For both, I
get 75-125ms, so the culprit isn't `combine` - it's `get-tube+obstacles`.
But the `get-tube+obstacles` code isn't doing anything in a particularly
slow way. It's just that making shapes is slow. As evidence, the game
goes at a good clip, though the tube looks terrible, if I add
"#:segments 8" to the call to `parametric-cylinder`.
(I could probably speed `parametric-cylinder` way up by writing it using
a lower-level interface to the 3D engine, but this would eventually come
up again.)
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 you don't mind, I have a couple of questions.
1. What was the most annoying surprise?
2. What was the most pleasant one?
Again, very cool!
Neil ⊥
____________________
Racket Users list:
http://lists.racket-lang.org/users