There are a bunch of these around, the keyword to look for is tiled display. It's been an active topic in the computer graphics and virtual reality community for the last couple years, and people have been building different sizes and using different alignment methods. The biggest ones I know are the NCSA 40 node and our 48 node system. Most of them are mono, there are two stereo-capable systems, one in Boston, the other one is ours.
The problem with the "rough alignment, use computer vision to sort it out" approach is the overlap area. Current projectors have a pretty sucky contrast (black to white) ratio. In the overlap areas all the blacks are added together, so the actual black you get is already pretty bright and there's nothing you can do about it. That's why we decided to go the hard route and do exact alignment. It's hard, but it's doable, and the results are pretty cool.
The presented method avoids that problem by design, so that's what makes it interesting, IMHO. Beside the fact that it doesn't need a separate air condition and 3 m back-projection space...
Which brings up another question: Has anyone done any serious investigation into context-modifiable
keyboards? My understanding on Star Trek is that their keyboards change their layouts depending on who's
there, and what they're doing. I've always thought something like that would be fantastic, say, for switching
into Quake or a flight sim -- make your keyboard LOOK like a control panel, so you don't have to remember
that "." is strafe or whatever...
Some years ago there was a programmable keyboard made by Siemens (and probably a bunch of other companis, but that's the one I saw) that had a little LCD display in every key. The LCD's resolution was pretty crappy (8x8 or so), but you could program every key differently.
There just wasn't any software that used it, and pretty much nobody used any other than the standard layout, so it didn't pay off. Maybe nowadays you could try it again, for gamers. You would need a better resolution though.
Another thing that would be interesting would be keyboards where you change the shape of the keys, too. You're just not gonna get force feedback on the keys, and that's a big problem. Would be cool, nonetheless.;)
Try www.cafepress.com, they let you upload your design and sell you (and everybody else) the shirts.
I have no personal experience with them, anybody care to comment how they work?
Re:I really don't get it...
on
Nvidia's NV20
·
· Score: 1
IMHO the main point is that the transform engine is seven times faster, while pixelfill is only two times faster.
Gfx HW is a pipeline, and a pipeline is only as fast as the slowest stage. The two main stages nowadays are transform and pixelfill. If the transform is busy because it has to transform bazillions of tiny triangles the pixelfill will idle. Same vice versa, for screen-filled, multi-textured, bump-mapped polygons the geometry part will sit there twiddling thumbs most of the time.
That's how a card can at the same time be 2 and 7 times faster. It all depends on the problem you throw at it.
The interesting side effect is that for a fill-limited scene you can increase the detail (i.e. use more polygons) without any effect on the framerate, the same goes for transform-limited scenes. The holy grail of graphics programming is to find the sweet spot so that all stages are busy all the time. But as that depends on the graphics card and the screen resolution and bits per pixel and other factors usually only the demo writers for the chip companies bother to do that. Thus most current games are written for the lowest level of customer hw and don't really use all the fancy features. Which is just fine for people like me who write their own software...;)
It's the same idea with patents. You patent a rather ingenious algorithm, and make an open
source(GPL) implementation. For anyone else to use that algorithm, they have to get permission
from you, else they'd be in violation of patent laws. In this case, EVERYONE has to ask
permission(unfortunatly, this includes Open Source initiatives). It's really no different than with
the regular GPL using copyright laws. Except it applies to everyone, so you can deny other Open
Source initiatives the priveledge of using your patented algorithm.
...and it's the easiest way to kill an offending Open Source initiative. Patent something useful, submit (or have somebody submit) it to an Open Source project, wait 'til they include it (because they have no practical chance at all to check if it's patented or not), and then sue their pants off.
They're essentially hosed. Even if the patented part is not fundamental and can be removed to get around your patent, they're in a legal battle they can't afford nor win. And after you did that to the first project leader, other people will be very careful to take over the project.
Software patents are dangerous for Open Source projects, because it's so easy to check if they infringe them. Closed Source is a lot safer because nobody knows what's inside.
Patents made a lot of sense in the age of the steam engine, when they were invented. They prevented somebody from looking at your solution, copy it and get away with it. They're much less useful for ideas (that's why you can't patent them), and software IMHO is a lot closer to ideas than steam engines.
In OpenGL you can pretty easily do some approximated transparency by patching one call (glBlendMode()) and forcing it to use GL_ONE,GL_ONE all the time. This just makes everything add up so for high depth complexity stuff will white out, but games are usually pretty good at keeping it below 3-4, so it should be ok. There is performance cost involved (framebuffer readback), but it shouldn't kill playability.
Wireframe is just as simple. Patch glPolygonMode() and off you go. Game cards are usually not very good at lines, but it's still playable, as Q3 shows. As the RivaStation article hints at, if you use stereo glasses, wireframe gives a pretty neat depth impression, so it's very usable.
If you patch the driver to return the correct settings it's undetectable for the application, we'd need certified drivers to check it. Not an easy thing to do and organize. What would you say if your brand new but as yet uncertified Radeon card was rejected by the Q3 server?
QT has not one but two easter eggs. Looking at $QTDIR/html you'll find easteregg.html and easteregg2.html. It contains a little text about content delivery vs. pretty graphics. The second version is the same but it BLINKs...
I would expect a lot more easter eggs in documentation, as they're a lot easier to make. They are harder to get through QA though (if they do their job right, that is).
Does anyone know of a way to get a free IP so you can run your own server from home?
You don't actually need a static IP, just use dynip or a number of other providers that offer DNS services for dial-up connections. Nearly as good as a static IP, but a lot cheaper.
Shadow casting (was: Re:Hmmm)
on
ATI Radeon 256
·
· Score: 1
What impressed me was the shadow casting stuff. I have been wondering about how best to implement shadows for some time. It is really a lot harder that you'd expect. I am very happy to see it done in hardware.
It's not really hard to do shadow casting in hardware, in fact standard OpenGL can do it, with a bit of creative use. See Nvidia's ShadowMap demo for an example. The source for a lot of the latest effects is Wolfgang Heidrich's thesis. Lots of really cool ideas, needs a reasonable computer graphics background, though.
If you want to get higher precision and speed you'll need some extensions, but not a lot. Depth textures and copy from framebuffer are enough, and have been available on high-end sgis for years, so the design is sort of stable.
Moral: with a good API and some creative use you can get really cool effects. Hardware can make it fast, but we'll have to see if the ATI chip delivers on that part...
Personally I would be much happier if the SGI people would spend their effort on ext3, which seems to be aiming for some of the same goals.
SGI had had XFS for a long time (1994?), and AFAIK it's one of the most stable high-performance filesystems out there. I think it's a great feat to Open Source something like this, which must have taken an enourmous amount of development work. Thus it wouldn't have made a lot of sense to re-introduce all their results into a new fs, because theirs was already working.
The biggest problem is that it took too long to get it out. The announcement concerning OS XFS was nearly a year ago IIRC. In the meantine Reiser and Ext3 took a lot of the limelight. I don't know the reasons why it took so long, probably having to remove patented IP or something like that. But it's a good thing it's getting close to completion.
I'm looking forward to using the same filesystem at home and at work. And I hope sgi continues pushing Open Source (OS Optimizer anyone?), and hopefully a bit faster than with XFS.
I'd like to use an alternative, but are there any that have comparable pricing for customers in Germany? Amazon.de delivers for free, and that's pretty hard to beat.
Slashdot Mirror
There are a bunch of these around, the keyword to look for is tiled display. It's been an active topic in the computer graphics and virtual reality community for the last couple years, and people have been building different sizes and using different alignment methods. The biggest ones I know are the NCSA 40 node and our 48 node system. Most of them are mono, there are two stereo-capable systems, one in Boston, the other one is ours.
The problem with the "rough alignment, use computer vision to sort it out" approach is the overlap area. Current projectors have a pretty sucky contrast (black to white) ratio. In the overlap areas all the blacks are added together, so the actual black you get is already pretty bright and there's nothing you can do about it. That's why we decided to go the hard route and do exact alignment. It's hard, but it's doable, and the results are pretty cool.
The presented method avoids that problem by design, so that's what makes it interesting, IMHO. Beside the fact that it doesn't need a separate air condition and 3 m back-projection space...
Some years ago there was a programmable keyboard made by Siemens (and probably a bunch of other companis, but that's the one I saw) that had a little LCD display in every key. The LCD's resolution was pretty crappy (8x8 or so), but you could program every key differently.
There just wasn't any software that used it, and pretty much nobody used any other than the standard layout, so it didn't pay off. Maybe nowadays you could try it again, for gamers. You would need a better resolution though.
Another thing that would be interesting would be keyboards where you change the shape of the keys, too. You're just not gonna get force feedback on the keys, and that's a big problem. Would be cool, nonetheless. ;)
I have no personal experience with them, anybody care to comment how they work?
Gfx HW is a pipeline, and a pipeline is only as fast as the slowest stage. The two main stages nowadays are transform and pixelfill. If the transform is busy because it has to transform bazillions of tiny triangles the pixelfill will idle. Same vice versa, for screen-filled, multi-textured, bump-mapped polygons the geometry part will sit there twiddling thumbs most of the time.
That's how a card can at the same time be 2 and 7 times faster. It all depends on the problem you throw at it.
The interesting side effect is that for a fill-limited scene you can increase the detail (i.e. use more polygons) without any effect on the framerate, the same goes for transform-limited scenes. The holy grail of graphics programming is to find the sweet spot so that all stages are busy all the time. But as that depends on the graphics card and the screen resolution and bits per pixel and other factors usually only the demo writers for the chip companies bother to do that. Thus most current games are written for the lowest level of customer hw and don't really use all the fancy features. Which is just fine for people like me who write their own software... ;)
They're essentially hosed. Even if the patented part is not fundamental and can be removed to get around your patent, they're in a legal battle they can't afford nor win. And after you did that to the first project leader, other people will be very careful to take over the project.
Software patents are dangerous for Open Source projects, because it's so easy to check if they infringe them. Closed Source is a lot safer because nobody knows what's inside.
Patents made a lot of sense in the age of the steam engine, when they were invented. They prevented somebody from looking at your solution, copy it and get away with it. They're much less useful for ideas (that's why you can't patent them), and software IMHO is a lot closer to ideas than steam engines.
Wireframe is just as simple. Patch glPolygonMode() and off you go. Game cards are usually not very good at lines, but it's still playable, as Q3 shows. As the RivaStation article hints at, if you use stereo glasses, wireframe gives a pretty neat depth impression, so it's very usable.
If you patch the driver to return the correct settings it's undetectable for the application, we'd need certified drivers to check it. Not an easy thing to do and organize. What would you say if your brand new but as yet uncertified Radeon card was rejected by the Q3 server?
Dirk
Documentation is a good place for easter eggs.
QT has not one but two easter eggs. Looking at $QTDIR/html you'll find easteregg.html and easteregg2.html. It contains a little text about content delivery vs. pretty graphics. The second version is the same but it BLINKs...
I would expect a lot more easter eggs in documentation, as they're a lot easier to make. They are harder to get through QA though (if they do their job right, that is).
You don't actually need a static IP, just use dynip or a number of other providers that offer DNS services for dial-up connections. Nearly as good as a static IP, but a lot cheaper.
It's not really hard to do shadow casting in hardware, in fact standard OpenGL can do it, with a bit of creative use. See Nvidia's ShadowMap demo for an example. The source for a lot of the latest effects is Wolfgang Heidrich's thesis. Lots of really cool ideas, needs a reasonable computer graphics background, though.
If you want to get higher precision and speed you'll need some extensions, but not a lot. Depth textures and copy from framebuffer are enough, and have been available on high-end sgis for years, so the design is sort of stable.
Moral: with a good API and some creative use you can get really cool effects. Hardware can make it fast, but we'll have to see if the ATI chip delivers on that part...
SGI had had XFS for a long time (1994?), and AFAIK it's one of the most stable high-performance filesystems out there. I think it's a great feat to Open Source something like this, which must have taken an enourmous amount of development work. Thus it wouldn't have made a lot of sense to re-introduce all their results into a new fs, because theirs was already working.
The biggest problem is that it took too long to get it out. The announcement concerning OS XFS was nearly a year ago IIRC. In the meantine Reiser and Ext3 took a lot of the limelight. I don't know the reasons why it took so long, probably having to remove patented IP or something like that. But it's a good thing it's getting close to completion.
I'm looking forward to using the same filesystem at home and at work. And I hope sgi continues pushing Open Source (OS Optimizer anyone?), and hopefully a bit faster than with XFS.
Does anybody know an alternative?