[racket] Crowdsourcing Pict3D's design

Thanks, and I'm glad you're having a good time. :)

Currently, the vertex data for frozen shapes is transferred every frame. 
The 3D engine is saturating your AGP bus.

I have plans to add either `freeze/send` or a `#:send?` argument to 
`freeze`, which will send the vertex data once to reside on the GPU, 
until the frozen Pict3D is garbage-collected.

Since you seem to know what you're talking about, I have a couple of 
questions for you about this.

  1. I've also considered having a data size threshold after which the
     data will be sent once. I'm not sure how to set this threshold, nor
     even whether it's a good idea. Any thoughts on automating the
     decision on what gets sent to the GPU?

  2. Attribute-updating functions such as `set-color` could be much more
     expensive for GPU-resident Pict3Ds. Here are a few options for
     dealing with it:

      A. Just update the attribute and re-freeze. If the old Pict3D hangs
         around on the GPU too, let the user deal with memory issues.

      B. Update the attribute and re-freeze, and warn the user somehow.

      C. Update the attribute and *don't* re-freeze.

     What do you think would be least annoying overall?

I also have plans to add engine support for indexed triangle meshes to 
reduce vertex data duplication. I haven't settled on the front-end API 
for this, but I'll probably introduce a `smooth` combiner and a `mesh` 
constructor.

I'll bump these up on my to-do list. Thanks for trying it out!

Neil ⊥

On 03/18/2015 09:23 AM, Berthold Bäuml wrote:
> Hi Neil,
>
> Pict3D is a really awesome project and fun to use!
>
> I have a question about the architecture and performance of Pict3D for scenes with millions of triangle. I want to visualize a robot having about 50 movable joints and each link of the robot is made from some 10^5 triangles (which works with no problem with 3D engines like Coin or OpenScenegraph). Has Pict3D to transfer all the triangles each time I want to render the robot with different joint positions or are they cached on the GPU and only the changed transformation matrices for each link have to be transferred? You mentioned that using "freeze" optimizes the transport (in my case I would freeze each link), but have freezed parts still to be transferred each time anew?
>
> I made a simple test program which draws some cylinders with many segments. Making the assumption that each segment is made of two triangles, even for about 4*10^5 triangles each frame already takes about 70ms to render on my computer consuming 100% of a cpu core. On the same computer I can render the full robot at 30Hz moving all its joints taking only 20% of the cpu.
>
> Did I miss something in making my example more performant or are there future plans for making pict3d faster?
>
> Best,
> Berthold
>
> simple example:
>
> #lang racket
> (require pict3d)
> (require pict3d/universe)
>
>
> (define p(combine
>            (for/list ([i (in-range 100)])
>              (freeze (set-emitted
>               (cylinder (pos i 0 0) (pos (+ i 1/2) 1/2 1/2) #:segments 2000)
>               (emitted "lightgreen" 2))))))
>
> (define (on-frame s n t)
>   (displayln (- t s))
>   t)
>
> (define (on-draw s n t)
>   p)
>
> (big-bang3d 0 #:on-frame on-frame #:on-draw on-draw)
>
>> On 09 Mar 2015, at 03:53, Neil Toronto <neil.toronto at gmail.com> wrote:
>>
>> Pict3D is finally ready for public consumption. You can install the package either in DrRacket using "File -> Install Package..." or from the command line using
>>
>>     raco pkg install pict3d
>>
>> The GitHub page is here:
>>
>>     https://github.com/ntoronto/pict3d
>>
>> All features are documented. The API is stable. I've verified that it runs on Racket 6.1.1 and the current development version. There are reports of it working on at least two Windows systems, two Mac OS X systems, and two Linux systems. It might not eat your graphics card.
>>
>> Current features:
>>
>> * Works in untyped and Typed Racket
>>
>> * Spheres, rectangles, triangles and quads with per-vertex attributes
>>
>> * A system of groups and affine (arbitrary parallel-line-preserving)
>>    transformations for sticking Pict3Ds together
>>
>> * Ray-against-scene and line-against-scene collision detection
>>
>> * Render targets: an interactive debugging view in DrRacket's REPL,
>>    `pict3d->bitmap` and `pict3d-canvas%`
>>
>> * big-bang3d (currently without networking)
>>
>> ------------------
>>
>> Now we get to crowdsourcing.
>>
>> I've reached the limits of what I can do without working on Pict3D full-time. In particular, I don't know whether the API is awkward or actually quite nice for the uses it'll be put to. I've drawn on some personal game design and coding experience, but that only goes so far.
>>
>> This is where you come in.
>>
>> 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.
>>
>> Anything is fair game for criticism, praise or suggestions: groups and pinning, distinguishing direction and position vectors, presence or lack of shapes you need, how to allow shader programming, file formats that would be nice to import models from, information that would be nice to have in the interactive debugging view, how to add texturing to the API, and even the tone of the documentation.
>>
>> I'm looking forward to your reports, all my little minions. Wait, did I say that out loud?
>>
>> Neil ⊥
>> ____________________
>> Racket Users list:
>> http://lists.racket-lang.org/users
>