|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>>> WHO said that you need to store the alternate meshes?
>
>> That would be Warp. ;-)
>
> No, I only mentioned lookup tables as being a solution to reducing the
> size of known meshes fast.
Ah, OK. I misunderstood then...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Oh yeah, and "Smoke". Simple little demo, but I have *no clue* how it
> manages to do that in realtime...
Using the GPU... the GPU is good for doing that sort of thing.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I've seen it done with other programs, too, like C compilers noticing
> they're compiling SPECmark suites and such.
Even car manufacturers get on this too. The ECU detects when the car is
being subject to the standard emissions and economy tests (to provide the
official figures for fuel consumption and CO2 emmissions) and then
deliberately runs in some special state to get better results.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> Although I'd think lower resolution polygon meshes for 27 different
>>> games and benchmarks does not belong to "the set of all things that can
>>> fit into 20 KB". ;-)
>>
>> It doesn't need to store the lower resolution meshes. It just needs to
>> store the logic to do reverse-subdivision of the meshes.
>
> ...and as *I* said originally, "wouldn't that be drastically more work
> than just rendering the high resolution mesh?"
You only need to do it once though, not every frame.
> Mesh subdivision being an extremely hard problem, and all that...
Not hard at all (just creating new vertices with weighted proportions of
neighbours), nor is un-subdividing (just checking pairs of triangles that
are almost planar to be combined).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> Oh yeah, and "Smoke". Simple little demo, but I have *no clue* how it
>> manages to do that in realtime...
>
> Using the GPU... the GPU is good for doing that sort of thing.
I'm still mystified (get it?) as to how it manages to render with
absolutely no visible grain of any kind to it. Even POV-Ray struggles to
do that given many *days* of rendering time...
Clearly some kind of trick must be involved.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> Oh yeah, and "Smoke". Simple little demo, but I have *no clue* how it
>>> manages to do that in realtime...
>>
>> Using the GPU... the GPU is good for doing that sort of thing.
>
> I'm still mystified (get it?) as to how it manages to render with
> absolutely no visible grain of any kind to it. Even POV-Ray struggles to
> do that given many *days* of rendering time...
>
> Clearly some kind of trick must be involved.
Not really, just utilising the GPU's ability to handle 3D textures and
smooth blending really efficiently. Don't forget the GPU version is not
scattering light like POV does...
This links shows some details about a DX10 smoke simulation, I expect a DX9
version uses a similar method (probably just not as efficient).
http://developer.download.nvidia.com/presentations/2007/gdc/RealTimeFluids.pdf
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> I'm still mystified (get it?) as to how it manages to render with
>> absolutely no visible grain of any kind to it. Even POV-Ray struggles
>> to do that given many *days* of rendering time...
>>
>> Clearly some kind of trick must be involved.
>
> Not really, just utilising the GPU's ability to handle 3D textures and
> smooth blending really efficiently. Don't forget the GPU version is not
> scattering light like POV does...
...GPUs can do 3D texturing now?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v7 nous apporta ses lumieres en ce 2007/11/04 12:49:
> scott wrote:
>
>>> I'm still mystified (get it?) as to how it manages to render with
>>> absolutely no visible grain of any kind to it. Even POV-Ray struggles
>>> to do that given many *days* of rendering time...
>>>
>>> Clearly some kind of trick must be involved.
>>
>> Not really, just utilising the GPU's ability to handle 3D textures and
>> smooth blending really efficiently. Don't forget the GPU version is
>> not scattering light like POV does...
>
> ...GPUs can do 3D texturing now?
Yes, and it's not even a new possibility! My old, totaly obsolete, and presently
unused, PCI Matrox Mystic was able to do some elementary 3D texturing, just not
to the same extent as todays cards and at a much lower resolution. It could'nt
do smooth blending or shading.
--
Alain
-------------------------------------------------
A modest man is usually admired; if people ever hear of him.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain wrote:
>> ...GPUs can do 3D texturing now?
> Yes, and it's not even a new possibility! My old, totaly obsolete, and
> presently unused, PCI Matrox Mystic was able to do some elementary 3D
> texturing, just not to the same extent as todays cards and at a much
> lower resolution. It could'nt do smooth blending or shading.
Oh, well... In that case, it's "merely" a matter of computing the gas
physics [to sufficiently believable precision]. That's a much easier task...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> I'm still mystified (get it?) as to how it manages to render with
>>> absolutely no visible grain of any kind to it. Even POV-Ray struggles to
>>> do that given many *days* of rendering time...
>>>
>>> Clearly some kind of trick must be involved.
>>
>> Not really, just utilising the GPU's ability to handle 3D textures and
>> smooth blending really efficiently. Don't forget the GPU version is not
>> scattering light like POV does...
>
> ...GPUs can do 3D texturing now?
They're just a set of 2D textures, fairly simple to implement even if you
card doesn't specifically support 3D textures.
The hard-ish bit is how to render them, but again you can just write some
ray-casting code into a pixel-shader that runs in real-time (as I think that
link I posted explains).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |