 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Andy, andy... you won't be getting much popularity here tossing around these
rough arguments...
Orchid Win7 v1 <voi### [at] dev null> wrote:
> And then, of course, I discovered POV-Ray.
you discovered povray after Cinema 4D and quake... okey, dokey...
> While computer games amuse
> themselves drawing polygons really, really fast, POV-Ray directly
> simulates things like curved surfaces, 3D textures, reflection,
> refraction, and so forth.
yeah, now put povray to directly simulate the curved surfaces of a woman's body.
You may use parametric surfaces if writing the right isosurface function is
proving too much of a challenge.
> But now we have the so-called unbiased renderers, the path tracers,
> whatever you want to call them. With POV-Ray I need to configure photon
> maps and set up area lights and waste hours tweaking and tuning
> radiosity parameters. And then I see a demo that runs IN A FRIGGING WEB
> BROWSER which uses my GPU to almost instantly render a Cornell box that
> would take multiple hours to draw with POV-Ray.
Truth be told, a cornell box today doesn't take even a minute in povray...
> I will freely admit, however, that almost all of the actual demo images
> are still suspiciously grainy. Which suggests that for "real" scenes,
> rendering still isn't instant. For example,
>
> http://tinyurl.com/87oyfmh
Scenes like that may take several hours on CPU, just like raytraced scenes in
the old days.
> You'd need some insane radiosity settings to get that out of POV-Ray.
> I'm not sure if it's even /possible/ to get that glow around the light
> sources.
the glow most likely is just a post-processing 2D effect.
> On the other hand, no one can deny the image is slightly grainy
> in places.
I prefer film grain rather than ugly splotches every corner. Also, a night
shot like that will look noisy in an actual photograph too. You either get the
best lenses possible or let it render for more time to gather more light
samples.
> And then I see something like this:
>
> http://tinyurl.com/7r72o7k
>
> At first glance, this is an amazing, near-photographic image. And then I
> notice THE POLYGONS! IT BURNS!!! >_< KILL IT WITH FIRE!
I don't note any polygons in particular, but the surfaces are all too flat and
regular, denouncing it as CG. Luxrender, like povray these days, is
conspicuously lacking in true artists rather than programmers trying to show off
the software.
That scene, I believe, took about 1 day or 2 to be that smooth if memory serves
me well...
This is a better scene, from an artist I truly enjoy, Enrico Cerica:
http://enricocerica.cgsociety.org/gallery/962953/
Modeled in Blender, rendered in Octane, a commercial path tracer that runs
exclusively on GPU.
Truly a photograph of a virtual environment.
> Now here's an interesting question: Does anybody know how this stuff
> actually /works/?
>
> In the simplest form, it seems that for each pixel, you shoot a ray
> backwards, and let it bounce off things at random angles (subject to how
> rough or smooth the materials are) until it finds a light source. For
> one ray, the result is pretty random. But average together a few
> bazillion rays, and slowly the random speckle converges to a beautiful,
> smooth (but slightly grainy) image.
http://www.pbrt.org/
The book explains all and source code for the renderer is GPLed. In fact, it's
the base for Luxrender.
> Wikipedia asserts "Contrary to popular myth, Path Tracing is /not/ a
> generalisation of ray tracing." This statement makes no sense
> whatsoever. :-P
To me pathtracing looks as much of a generalisation of raytracing as raytracing
was of raycasting (which BTW, is progressively being more used in games for
things like LOD management). But I believe they were talking about how it is
not simply raytracing with (possibly) infinite ray bouncing.
> Does this paper make /any/ sense to anybody?
certainly not to someone without the particular math and rationale insight. :)
> I'd almost be tempted to write a renderer myself - except that running
> on a CPU, it will undoubtedly take several billion millennia to draw
> anything. (There's a /reason/ nobody has tried this until today...)
No, just a few hours or days like povray back in 1990's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/24/2012 2:20 PM, Orchid Win7 v1 wrote:
> The SDL user interface is radical in its own way too. With a visual
> modeller, it would be ridiculously difficult to position a sphere so
> that it exactly coincides with the end of a cylinder. With SDL, it's
> trivial.
Number one irritation that I have with the damn things. Wings 3D you can
bring up the "literal location", or what ever, find the real center, and
then move your other object to coincide, but it would still be better if
it combined that with the hierarchical system in say Moray, so you could
just "uncurve/mode/rotate" the damn thing, relative what you are trying
to position it against, and fix the problem.
Still, you can get a version of Wings, from here:
http://s331378245.onlinehome.us/
which includes a mess of stuff for everything from Greebling, to Carve
3D CSG functions (which appear to be buggy, as I reported, when you try
to CSG an object/surface, with a face, instead of where you cross "two"
faces (i.e., a side). No idea if they have figured out where the bug in
that is or not, but someone else made the code for the library, so...
But, this is the sort of thing that **should be** trivial, if the people
that made the application took any thought, at all, to the idea that
people might want to be at all precise about anything, instead of just
throwing it in, and hoping. lol
BTW though-- if they can find the bugs, Carve 3D would be a crazy
addition to Moray. ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 24/06/2012 10:20 PM, Orchid Win7 v1 wrote:
>
> The SDL user interface is radical in its own way too. With a visual
> modeller, it would be ridiculously difficult to position a sphere so
> that it exactly coincides with the end of a cylinder. With SDL, it's
> trivial.
you can type coordinates to get an exact location. In Bishop3D you can
enter formulas as well. Both Moray and Bishop3D have a snap function
when placing objects using the mouse.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 25/06/2012 01:09 AM, nemesis wrote:
> Andy, andy... you won't be getting much popularity here tossing around these
> rough arguments...
I'm sure I can't be the only person feeling a little dissatisfied, or at
least a bit concerned.
>> And then, of course, I discovered POV-Ray.
>
> you discovered povray after Cinema 4D and quake... okey, dokey...
What, that's a problem somehow?
I didn't say they were /created/ in that order, merely that I discovered
them in that order. If I said that I discovered Queen before I
discovered Bach, nobody would be the slightest bit surprised, despite
the /several hundred years/ between these. :-P
>> While computer games amuse
>> themselves drawing polygons really, really fast, POV-Ray directly
>> simulates things like curved surfaces, 3D textures, reflection,
>> refraction, and so forth.
>
> yeah, now put povray to directly simulate the curved surfaces of a woman's body.
>
> You may use parametric surfaces if writing the right isosurface function is
> proving too much of a challenge.
Drawing such a thing is equally impossible with POV-Ray or with a mesh
renderer, so it's not a useful comparison. (Although, maybe if I had
infinite point-cloud dartah... :-P )
Saying that, you might be able to model something acceptable with blobs.
Or maybe if POV-Ray supported spline surfaces...
>> But now we have the so-called unbiased renderers, the path tracers,
>> whatever you want to call them. With POV-Ray I need to configure photon
>> maps and set up area lights and waste hours tweaking and tuning
>> radiosity parameters. And then I see a demo that runs IN A FRIGGING WEB
>> BROWSER which uses my GPU to almost instantly render a Cornell box that
>> would take multiple hours to draw with POV-Ray.
>
> Truth be told, a cornell box today doesn't take even a minute in povray...
Funny you should say that. I spent yesterday trying to set up an
animation of a Cornell box, and it appears that to get stable lighting,
I'm going to have to crank the radiosity settings up to the point where
it takes about 30 minutes per frame...
>> I will freely admit, however, that almost all of the actual demo images
>> are still suspiciously grainy. Which suggests that for "real" scenes,
>> rendering still isn't instant.
>
> Scenes like that may take several hours on CPU, just like raytraced scenes in
> the old days.
There's a /reason/ POV-Ray does all this complicated radiosity trickery
rather than just directly simulating the whole thing. It's to make it
render in less than a decade. ;-) The trick, it seems, is to use the GPU
to make it faster.
>> You'd need some insane radiosity settings to get that out of POV-Ray.
>> I'm not sure if it's even /possible/ to get that glow around the light
>> sources.
>
> the glow most likely is just a post-processing 2D effect.
Can you actually do that? I mean, automatically figure out all the parts
of the image which are bright enough to need glow? I suppose the only
way it would fail is if there's a curved reflection of something that
glows; the glow should be curved, but if it's post-processed, it
wouldn't be.
>> On the other hand, no one can deny the image is slightly grainy
>> in places.
>
> I prefer film grain rather than ugly splotches every corner.
Sure. Same here.
(I am surprised nobody has come up with a filter to estimate what's
sampling noise and attempt to filter it out... It can't be that hard.)
>> And then I see something like this:
>>
>> http://tinyurl.com/7r72o7k
>>
>> At first glance, this is an amazing, near-photographic image. And then I
>> notice THE POLYGONS! IT BURNS!!!>_< KILL IT WITH FIRE!
>
> I don't note any polygons in particular
You didn't notice that the table is hexagonal??
> but the surfaces are all too flat and
> regular, denouncing it as CG. Luxrender, like povray these days, is
> conspicuously lacking in true artists rather than programmers trying to show off
> the software.
Heh, well, I wouldn't hold that against it. ;-)
> That scene, I believe, took about 1 day or 2 to be that smooth if memory serves
> me well...
That's /a lot/ of render time, man... o_O
>> Now here's an interesting question: Does anybody know how this stuff
>> actually /works/?
>
> http://www.pbrt.org/
>
> The book explains all and source code for the renderer is GPLed. In fact, it's
> the base for Luxrender.
I'll have to go read that.
>> Wikipedia asserts "Contrary to popular myth, Path Tracing is /not/ a
>> generalisation of ray tracing." This statement makes no sense
>> whatsoever. :-P
>
> To me pathtracing looks as much of a generalisation of raytracing as raytracing
> was of raycasting
Indeed.
>> I'd almost be tempted to write a renderer myself - except that running
>> on a CPU, it will undoubtedly take several billion millennia to draw
>> anything. (There's a /reason/ nobody has tried this until today...)
>
> No, just a few hours or days like povray back in 1990's.
A day is a /long/ time to wait while debugging your code to see if it
works correctly. o_O
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 25/06/2012 9:27 AM, Invisible wrote:
>> yeah, now put povray to directly simulate the curved surfaces of a
>> woman's body.
>>
>> You may use parametric surfaces if writing the right isosurface
>> function is
>> proving too much of a challenge.
>
> Drawing such a thing is equally impossible with POV-Ray or with a mesh
> renderer, so it's not a useful comparison. (Although, maybe if I had
> infinite point-cloud dartah... :-P )
>
> Saying that, you might be able to model something acceptable with blobs.
> Or maybe if POV-Ray supported spline surfaces...
>
Ian MacKay has made a credible attempt in his TC-RTC entry Lilli Marlene
using CSG.
And Poser meshes can fool many people. The shapes are very good now.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 25 Jun 2012 08:27:12, Invisible wrote:
> What, that's a problem somehow?
I shouldn't be surprised by your quirks by now, but it still happens now and
then... :p
>> yeah, now put povray to directly simulate the curved surfaces of a woman's body.
>>
>> You may use parametric surfaces if writing the right isosurface function is
>> proving too much of a challenge.
> Drawing such a thing is equally impossible with POV-Ray or with a mesh
> renderer, so it's not a useful comparison. (Although, maybe if I had
> infinite point-cloud dartah... :-P )
http://forums.cgsociety.org/showthread.php?f=121&t=1036380
http://forums.cgsociety.org/showthread.php?f=121&t=829134
Should I also point out several of the Poser meshes people have been posting in
povray images for years? Or game and movie meshes?
Hint: they are not scans of human models. People have been sculpting digitally
for quite some time now in software like Z-Brush and then generate from that a
less dense polygon mesh with normal mapped details.
> Saying that, you might be able to model something acceptable with blobs.
Not really. And this:
http://tc-rtc.co.uk/imagenewdisplay/stills/389/Lilli_Marlene.html
truly shows povray's age... it would be terribly unnaceptable as a scene in a
game today, let alone in the upcoming generation of game hardware... seems like
those perfect curves don't make for quality renders...
>> Truth be told, a cornell box today doesn't take even a minute in povray...
> Funny you should say that. I spent yesterday trying to set up an
> animation of a Cornell box, and it appears that to get stable lighting,
> I'm going to have to crank the radiosity settings up to the point where
> it takes about 30 minutes per frame...
Then you're doing it wrong. Radiosity is there to provide only smooth indirect
lighting effects, not extra shadows or something. If it's getting too long and
still displaying lots of lame splotches, you're not using it like it was meant
to be used...
>> Scenes like that may take several hours on CPU, just like raytraced scenes in
>> the old days.
> There's a /reason/ POV-Ray does all this complicated radiosity trickery
> rather than just directly simulating the whole thing. It's to make it
> render in less than a decade. ;-) The trick, it seems, is to use the GPU
> to make it faster.
It doesn't take a decade, never did. It takes hours or days like you were used
to, but produces on CPUs today far better results than what was possible with
povray back then. That's not even accounting for GPUs, which can bring it down
to minutes or barely more than an hour.
>> the glow most likely is just a post-processing 2D effect.
> Can you actually do that? I mean, automatically figure out all the parts
> of the image which are bright enough to need glow?
Yes, it's a trivial 2D effect in most 2D graphical editing software. Luxrender
comes with a few such filters.
> You didn't notice that the table is hexagonal??
oh, now that you bring it up, I see it. Yeah, the guy evidently overlooked it,
but if it wasn't for the contrast with the bright light outside, it wouldn't be
noticeable anyway. Hey, keeping geometry as simple as possible always helps
with render times. I wonder how tesselation in nextgen game hardware will help
that...
Other than that, you don't note any edges on the smooth chairs and table curved
legs...
> A day is a /long/ time to wait while debugging your code to see if it
> works correctly. o_O
that's the beauty with progressive rendering: you don't need to wait 8 hours
for the first few rows of the image to be ready and after 36 hours notice the
last few rows show horrid splotches near the table legs: you get a rouch noisy
preview early on that already shows where every shadow is and all colors
right...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/24/2012 23:52, Patrick Elliott wrote:
> Still, you can get a version of Wings, from here:
I must say that SketchUp was the first (and only) modeler I've ever used
where I wasn't manipulating the modeler's data structures. I didn't have to
know anything about how it's represented internally. You want a box with a
circle drilled thru it? Make a box, draw a circle, push the circle out the
other side. You're done.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/28/2012 5:54 PM, Darren New wrote:
> On 6/24/2012 23:52, Patrick Elliott wrote:
>> Still, you can get a version of Wings, from here:
>
> I must say that SketchUp was the first (and only) modeler I've ever used
> where I wasn't manipulating the modeler's data structures.
I haven't tried the most recent version, but I also felt the same way
about Sculptris (http://www.pixologic.com/sculptris/), which is a free
zbrush-like modelling program.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 29/06/2012 01:54 AM, Darren New wrote:
> On 6/24/2012 23:52, Patrick Elliott wrote:
>> Still, you can get a version of Wings, from here:
>
> I must say that SketchUp was the first (and only) modeler I've ever used
> where I wasn't manipulating the modeler's data structures. I didn't have
> to know anything about how it's represented internally. You want a box
> with a circle drilled thru it? Make a box, draw a circle, push the
> circle out the other side. You're done.
...except that, eventually, you discover that your "circle" is actually
an N-gon. Which seems an unfortunately break in the modeller's
abstraction...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/28/2012 23:20, Orchid Win7 v1 wrote:
> ...except that, eventually, you discover that your "circle" is actually an
> N-gon. Which seems an unfortunately break in the modeller's abstraction...
Yes. However, it's still way better than having to tell the tool how to
connect the circle to the edges, like with Wings.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
