[racket] Crowdsourcing Pict3D's design

Hi Neil,

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

My first intuition was to keep the data on the GPU and the "current" pict3d synchronized. Each time a pict3d should be rendered all frozen sub-picts which are not already on the GPU are sent and all data which is not part of the current pict3d is deleted from the GPU (or can be kept there for caching).

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

I am no expert at all but only a user with large models to work with ...

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

You talk only about the frozen data? Then I would do it the way described above.

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

I am not sure but don't modern OpenGL versions have the possibility to change the color without having to retransfer the complete geometry data anew (kind of a color array and a index array)?

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

Option A in combination with he "synchronization" scheme above would be my favorite: completely transparent to the user. Or I am missing something?

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

A 'mesh' constructor looks obvious to me. But what do you mean by a 'smooth' combinator? Should meshes combine differently than other primitives?

Best,
Berthold

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

-- 
-----------------------------------------------------------------------
Berthold Bäuml -- Head of Autonomous Learning Robots Lab
DLR, Robotics and Mechatronics Center (RMC)
Münchner Str. 20, D-82234 Wessling
Phone +49 8153 282489
http://www.robotic.de/Berthold.Baeuml