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.toro...@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
____________________
Racket Users list:
http://lists.racket-lang.org/users
