Hi Daniel,
Daniel Sperka wrote:
> Here's a bit more about what I'm doing.
>
> My application simulates motion over a ground plane. The ground plane is
> populated with random dots. I've modelled the groundplane as a set of
> grids. Every time the camera beacon is moved I update the list of grids
> which are to be drawn by projecting the viewing volume onto the plane
> (there's other constraints which make this a good approximation). As
> grids fall out of the view they are returned to the pool. As new grids
> are required they are drawn from the pool, re-populated with random
> dots, and flagged for drawing on the next frame.
>
Given that they're only dots, a quick option would be to rotate them
randomly before reusing them, to add some randomness without having to
regenerate the geometry.
> The other complication is that of frame-by-frame control. We would like
> to update the content of the scene on each frame and ensure that the
> specified scene is drawn - without fail - for minutes at a time. That's
> been another battle with drivers, the operating system and video cards
> that we needn't go into right now ;) I can say that this basic goal has
> been met with rather pedestrian video cards and CPUs, and we've achieved
> 100FPS with some reliability (though it seems to make the video cards
> rather unhappy.)
>
Can you say a little bit more about that? I usually have large scenes
that don't go that fast anyway. ;)
> For various scientific reasons the dots must be random, and we don't
> want to re-use dots. Thus, the requirement that I re-populate these dots
> with some frequency. Not every frame, though! Thus I leave display lists
> ON, as the dots on a given grid will remain on the screen for a second
> or so before they are dumped and re-populated. The grid sizes and dot
> density are controlled by the experimenter, and so a wide range of
> values must be supported.
>
> Sorry for the long-winded explanation.
>
> [ BTW, I'll post some stuff in the applications gallery one of these
> days or weeks. There's a big conference coming up, however, and we've
> got a lot to do so people can get preliminary data to show. I suppose
> you know how that goes ;) ]
>
Yup. But keep the Gallery in mind! ;)
> Now, back to the question. I am concerned that under some circumstances
> this re-population of dots may take too much time. Unfortunately I can't
> yet discern where that time may be taken up - either in the generation
> of randoms, the movement of the dots across the bus to the video card,
> or in the rendering on the card itself. Currently we haven't pushed our
> application to this threshhold, but as our scenes become more complex I
> cannot be sure there won't be trouble.
>
Probably all of the above.
> So, my thought becomes - why not pre-populate the card's memory with
> generated display lists of points. I'm guessing that a list of 1000
> points will take roughly 1K * 4bytes * 3(xyz) = 12K memory. On a card
> with 64Mb there ought to be room for thousands of these. When the time
> comes to repopulate the points for a grid rectangle, I'd simply change
> the display list ID that the node core uses with no cost in transporting
> that information to the card, compiling the list, etc. All that cost
> would be paid prior to the start of an experimental trial where there's
> plenty of time for such things.
>
You can dot he same thing by just creating a pool of Geometries and
reusing them. It won't be totally non-repeated, but you can use the
rotation idea above to spice it up, or you can have overlapping
geometries to add some randomness, or if you want to go fancy you can
add a shader to your material that does a pseudo-random transformation
based on a parameter than you can change randomly (like a weird rotation
around some angle that depends on the point's position or something like
that).
> Don't games do this type of thing loading textures onto the card?
>
Yes, but they just limit the amount of updated data and tweak it until
it works. But for your problem I think it might be easier to just avoid
it, if that's acceptable for the researchers.
Hope it helps
Dirk
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
