Dirk Reiners wrote: > 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. >
I'd already suggested that, but it didn't pass the "sniff test". Everyone agreed it'd probably be fine, but nobody wanted to try to explain it to the referees on a paper or grant proposal committee. >> 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. ;) > I can't help your large scenes. We're using Radeon r200 cards (the 9000's work nicely, but the 9200SE's are much slower). With some modeline games I can set up the cards to run at 100FPS. Problem is that there are often strange visual artifacts on the screen, which is a no-no for visual neuroscience. Then there's the risk of destroying the monitors. . . . >> 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 > Thanks, Dirk. Based on your suggestions (and those of Carsten) I'm looking into setting up a worker thread to re-populate the used geometries with fresh random numbers. There's usually time to do this while we wait for buffer swaps (generally we have 5-10ms of waiting...). Dan > > ------------------------------------------------------------------------- > 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 > > ------------------------------------------------------------------------- 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
