POV-Ray : Newsgroups : povray.general : Scanline rendering in POV-Ray : Re: Scanline rendering in POV-Ray Server Time
4 Aug 2024 22:16:13 EDT (-0400)
  Re: Scanline rendering in POV-Ray  
From: Patrick Elliott
Date: 3 Jun 2003 15:07:38
Message: <MPG.19469fa441aabf3989807@news.povray.org>
In article <web.3edc9d6bc13294582ff34a90@news.povray.org>, 
tom### [at] compsocmanacuk says...
> Patrick Elliott wrote:
> >With the number of component we could fit into a new card
> >the result would be no bigger than an existing NVidia card, however the
> >development time needed to produce the chip, make sure it was stable and
> >then pray that game companies that are used to using the cheats supplied
> >through OpenGL and DirectX will actually use it makes the odds of anyone
> >seeing such a card on the market any time soon very unlikely.
> 
> Cheats? Was there ever a 30fps algorithm free of them? :-)
> 
True enough, but in this case I mean 'cheat' as in faking real geometry 
like boxes and spheres using triangles. I consider it a cheat because it 
takes advantage of the existing hardware capability to produce something 
that only looks real by using so many triangles that you can't place 
anything else in the scene with it. That is the nature of most cheats, 
something that looks good enough for you purpose, but doesn't really 
reproduce the result accurately.

> >The irony being that in many cases you have to upload large chunks of
> >additional geometry and pre-made textures every few seconds in a game,
> >while a true raytrace engine would only have to upload terrain geometry
> >and those textures you couldn't produce using procedural systems (which for
> >most games would be maybe 10% of them...)
> 
> Why won't a raytracing card have to load new geometry regularly? It's not
> necessarily going to know ahead of time which objects will be needed during
> a game, and they are not all going to fit in memory at the same time for a
> modern game.
> 
True, but some things don't need to be fed back into in continually and 
those bases on primitives would take less room to store, meaning you can 
leave more of them in memory than normal. This should cut in half the 
amount of stuff you have to cram into the card in each frame, possibly 
more.

> Procedural textures will have to be calculated by the graphics card, which
> surely has enough to do already (if you get the CPU to do it and send it to
> the graphics card, you might as well send an image). I thought anyway that
> procedural textures are not specific to raytracing?
> 
Think some new cards may use them, but the same issue existed for them as 
for a true card based engine, the methods used to produce them where 
simply too complex to 'fit' in the existing architecture.

> Whilst I'm sure that, given sufficient time, you could reproduce 90% (or
> 100%) of game image textures with procedural textures, the question surely
> is whether it is worth the extra time taken to generate the textures in the
> first place, every frame. I can especially see problems producing things
> like text at speed.
> 
Kind of hard to say, since the option isn't exactly common or if it does 
exist is not used from what I have seen.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.