Just a follow-up on what I've done, and a follow-up question. On second thought, I'll post a new thread on that one.
AFter some investigation, I found that there's a reliable way to estimate the number of planar grids we need for a given experimental trial run (I advise the experimenters to double that estimate). The application generates that many geometries and populates them with randoms. I use a custom node core, similar to a Switch, except that there is an unlimited number of possible nodes to be turned on. A method in the node is triggered every time the camera is moved. The method projects the frustrum down onto the plane, figures out which grids have fallen out of the view and which grids are now required, adjusts scaling and translation for the new grids. A list of the child indices corresponding to the geometries in use is kept. Then, when the core's "enter" function is called during rendering, its a simple matter to add the required child nodes to the active node list. I force an initial rendering pass where ALL the newly generated geometries are put in the list, so their display lists are compiled. There is a threshhold where swapping starts happening, but that is easily avoidable. [ I wish these old Dells weren't so fussy about the type of memory they take! ] Thanks to everyone who chimed in and offered help! Dan Daniel Sperka wrote: > 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 > > ------------------------------------------------------------------------- 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
