Nvidia Release NV40 effects videos
- Thread starter pocketmoon66
- Start date
LOL - They read Deano'sarticle! 
{Sniping}Waste
Regular
For such a small demo, it is sure choppy. The Water Simulation was choppy and didn't look good at all. Im shock that they would put this out with problems like this.
Im not being a fan boy but I would not show my demo on my next card that runs choppy. It make the new card look slow and/or buggy.
Im not being a fan boy but I would not show my demo on my next card that runs choppy. It make the new card look slow and/or buggy.
I was impressed by "3d painting", but then the "many lights" demo just floored me!
VERY impressive looking stuff, if it works.
I'm still downloading the water...
VERY impressive looking stuff, if it works.
I'm still downloading the water...
(Whoah, what happened to the board? )
I looked at all of them, and DAMN, they look SWEET. Dunno if 32-bit performance with NV40 will suck or not, but it seems visuals are good enough with just 16-bit buffers.
The guy speaking in the multiple lights demo mentions branching is required (and not just looping as the title suggest), and considering the number of lights on that teapot and the framerate, it doesn't seem as if performance takes that bad a hit after all.
The water in the last demo looks like total pap though. It's a demo of a boat gliding around in a pond of KY gel or some such, hahaha. Technically it looks good, with reflections, refractions etc, but the water dynamics are all screwed up. Not that any of this is NV40's fault though; like I said, technically it looks good.
The motion blur also seems nice. I dunno how the heck that's done, because traditionally it's been done by blending the previous frame with the current (which makes it look bad if there are large movements inbetween frames; esp if the camera rotates), but here it actually looks pretty decent! When the guy pauses the demo and spins the pot manually one can see it's not just blending the previous frame. I guess it must render the scene multiple times for each screen update and combine them or something like that. Hard to tell from a blurry video.
Also, the painting demo was AWESOME. I played around with a 2D paint program on a friend's Powermac back in the mid-90s, it was slow as f*ck with large brushes. I want a paint program like I saw there! Better UI, sure, but the speed and quality.... YUMMMM! And the fact it re-renders the entire screen in realtime when a slider is moved, AWESOME!
Wow. NV40 looks as if it might actually kick butt IMO! Nvidia could have a winner on its hands this time 'round, FP filtering, shaders v3.0, possibly 16 pixel pipes, GDDR3... Mm-mm. Lookin good!
)I looked at all of them, and DAMN, they look SWEET. Dunno if 32-bit performance with NV40 will suck or not, but it seems visuals are good enough with just 16-bit buffers.
The guy speaking in the multiple lights demo mentions branching is required (and not just looping as the title suggest), and considering the number of lights on that teapot and the framerate, it doesn't seem as if performance takes that bad a hit after all.
The water in the last demo looks like total pap though.
It's a demo of a boat gliding around in a pond of KY gel or some such, hahaha. Technically it looks good, with reflections, refractions etc, but the water dynamics are all screwed up. Not that any of this is NV40's fault though; like I said, technically it looks good.The motion blur also seems nice. I dunno how the heck that's done, because traditionally it's been done by blending the previous frame with the current (which makes it look bad if there are large movements inbetween frames; esp if the camera rotates), but here it actually looks pretty decent! When the guy pauses the demo and spins the pot manually one can see it's not just blending the previous frame. I guess it must render the scene multiple times for each screen update and combine them or something like that. Hard to tell from a blurry video.
Also, the painting demo was AWESOME. I played around with a 2D paint program on a friend's Powermac back in the mid-90s, it was slow as f*ck with large brushes. I want a paint program like I saw there! Better UI, sure, but the speed and quality.... YUMMMM! And the fact it re-renders the entire screen in realtime when a slider is moved, AWESOME!
Wow. NV40 looks as if it might actually kick butt IMO!
Nvidia could have a winner on its hands this time 'round, FP filtering, shaders v3.0, possibly 16 pixel pipes, GDDR3... Mm-mm. Lookin good!
The motion blur demo looked pretty decent, but the graininess of the video kind of made it hard to discern details.
It looked like their blur implementation might be of rather fixed utility for a game, though probably more useful for animation.
The demo only had the teapot rotating along that one axis at a fixed speed, and the blur still showed up even when the rotation was paused. When the demonstrator rotated the teapot on a vertical axis at the very end, there was of course no motion blur that fit that direction of rotation.
Perhaps the shader used was programmed to only function in the original direction. I would have been more impressed if it were fully interactive and showed blur while the user pushed the teapot around, but that doesn't seem to be quite the case right now.
This looked to me like the implementation would be better suited for a cinematic where all viewpoints and object behavior is known and controlled.
What kind of shader do you think was being used? If I were going to try to accurately model the blur, I guess I would try to track which vertices had the greatest displacement between frames. I suppose that would mean a vertex shader.
The many lights demo was cool. I wonder if it would be possible to run motion blur at the same time.
It looked like their blur implementation might be of rather fixed utility for a game, though probably more useful for animation.
The demo only had the teapot rotating along that one axis at a fixed speed, and the blur still showed up even when the rotation was paused. When the demonstrator rotated the teapot on a vertical axis at the very end, there was of course no motion blur that fit that direction of rotation.
Perhaps the shader used was programmed to only function in the original direction. I would have been more impressed if it were fully interactive and showed blur while the user pushed the teapot around, but that doesn't seem to be quite the case right now.
This looked to me like the implementation would be better suited for a cinematic where all viewpoints and object behavior is known and controlled.
What kind of shader do you think was being used? If I were going to try to accurately model the blur, I guess I would try to track which vertices had the greatest displacement between frames. I suppose that would mean a vertex shader.
The many lights demo was cool. I wonder if it would be possible to run motion blur at the same time.
Bouncing Zabaglione Bros.
Legend
I'd agree on the choppyness. Given these seem to have been videoed directly off the screen, and that the mouse and voiceover were smooth, the rendering itself and not the encoding seems to be very choppy. This doesn't seem to bode well for actually using any of this stuff (except as fluff) in realworld games given the simplicity of what was being rendered.
I did like the paint demonstration. That was much more impressive and much smoother.
I did like the paint demonstration. That was much more impressive and much smoother.
Yes, virutally any paint program (photoshop, paintshop pro, etc)
The only video that looked choppy to me was the motion blur one, and it's hard to tell if the big "stutters" were caused by the guy messing with the mouse or pause button, since they occured right after he was pausing it.
The water demo did not look choppy when the camera wasn't moving, leading me to believe the choppiness comes from bad movement controls.
The only video that looked choppy to me was the motion blur one, and it's hard to tell if the big "stutters" were caused by the guy messing with the mouse or pause button, since they occured right after he was pausing it.
The water demo did not look choppy when the camera wasn't moving, leading me to believe the choppiness comes from bad movement controls.
{Sniping}Waste
Regular
DemoCoder, I saw choppieness in all of them. The paint one was the smothest but the others were choppy.
