Invisible wrote:
> Yes, because crude approximations to cylindrical columns look so much 
> more photo-realistic than actually cylindrical columns. Oh, wait...

Consider what happens if your "approximation" results in sub-pixel-sized 
triangles. Then it becomes no more an approximation than yours does, 
considering *your* picture is also made out of pixels.

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

>> Yes, because crude approximations to cylindrical columns look so much 
>> more photo-realistic than actually cylindrical columns. Oh, wait...
> 
> Consider what happens if your "approximation" results in sub-pixel-sized 
> triangles. Then it becomes no more an approximation than yours does, 
> considering *your* picture is also made out of pixels.

...until you have a reflection of the object where the triangles appear 
bigger. Or a shadow cast in the wrong direction.

But yeah, sure, I am apparently the only person here who thinks that 
real curves are superior to faked ones. I'll grant you that one.

Post a reply to this message

Invisible escreveu:
> nemesis wrote:
> 
>> What I really want to see is you stop whinning and showing a perfectly 
>> curved phone better than the fake-curved phone scott provided.  You 
>> have ten minutes.
>>
>> or just STFU.
> 
> Except that it *isn't* perfectly curved. It's fake. It's just flat 
> surfaces and jaggid lines filtered to make it seem smooth.

It doesn't matter if they are fake if they look perfectly smooth.  Same 
can be said of Pixar stuff.

BTW, the 10 minutes are gone, so you should just STFU instead of 
whinning without giving solid examples to your (false) claims.

>> psst:  there's a displace modifier too.
> 
> How can you displace a triangle?

You don't, you displace meshes.  Dense meshes.

>> Why do you insist on being stubborn?
> 
> I think because fundamentally I dislike trickery. Modelling solid 
> objects as true solids with a real inside and outside, and real curves, 
> and real patterns, etc. seems so much superior to faking it with lots of 
> straight lines and pixels.

Fine, give us your perfectly curved SDL phone and we'll all agree with 
you.  I'll give you the benefit of doubt and more 10 minutes.

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

Invisible escreveu:
>>> Yes, because crude approximations to cylindrical columns look so much 
>>> more photo-realistic than actually cylindrical columns. Oh, wait...
>>
>> Consider what happens if your "approximation" results in 
>> sub-pixel-sized triangles. Then it becomes no more an approximation 
>> than yours does, considering *your* picture is also made out of pixels.
> 
> ...until you have a reflection of the object where the triangles appear 
> bigger. Or a shadow cast in the wrong direction.
> 
> But yeah, sure, I am apparently the only person here who thinks that 
> real curves are superior to faked ones. I'll grant you that one.

I grant you don't know what an integral means.  I'm also aware that you 
long lost reasoning in your will to spill poison.  I also notice you are 
not listening to us in your lone quest...

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

Darren New escreveu:
> nemesis wrote:
>> I see.  A limited scripting language with no real support for modules 
>> or functions is better-suited for all those than a more general one.
> 
> Yep. I actually didn't use an # directives in the outputs. Just 
> thousands of individual objects, with each scene still only taking a 
> second or two to parse.

You have loops, ifs and macros.  I didn't say otherwise.

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

Invisible wrote:
> But yeah, sure, I am apparently the only person here who thinks that 
> real curves are superior to faked ones. I'll grant you that one.

Real curves are superior. They're just not always worth the effort.

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

Warp escreveu:
>   How many triangles can you find in the attached image?

BTW, I find it both funny and ironic that it started with a puzzle about 
a triangle and went on to be a huge hate thread about Blender, 
polygon-based modelling and so forth... :)

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

nemesis wrote:
> Darren New escreveu:
>> nemesis wrote:
>>> I see.  A limited scripting language with no real support for modules 
>>> or functions is better-suited for all those than a more general one.
>>
>> Yep. I actually didn't use an # directives in the outputs. Just 
>> thousands of individual objects, with each scene still only taking a 
>> second or two to parse.
> 
> You have loops, ifs and macros.  I didn't say otherwise.

No, POV has loops, ifs and macros. *I* actually didn't use them.

Oh, are you trying to compare SDL against Blender's Python? Yeah, I tried 
writing code in blender's Python. It doesn't work. It's buggy. It's 
undocumented or at best very poorly documented.

So, in this specific instance, yeah, SDL is actually a better output 
language than Blender's Python interface, if that's what you mean.

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

nemesis wrote:
> a huge hate thread about Blender, 

I find it funny that you're reading "hate" into any of the posts.

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

Darren New escreveu:
> tried writing code in blender's Python. It doesn't work. It's buggy. 

The hundreds of Blender scripts both official and by users out there 
seem to contradict that.

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

Darren New escreveu:
> nemesis wrote:
>> a huge hate thread about Blender, 
> 
> I find it funny that you're reading "hate" into any of the posts.

I find it funny that you don't notice it in-between the lines.

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

nemesis wrote:
> Darren New escreveu:
>> tried writing code in blender's Python. It doesn't work. It's buggy. 
> 
> The hundreds of Blender scripts both official and by users out there 
> seem to contradict that.

It only took me writing two and having them both not work to convince me 
otherwise.

Note that it's possible to be "buggy" and yet still work for lots of people. 
Maybe I was just doing things that nobody else tried to do, or if they tried 
and it failed, they didn't complain or try to fix it but rather just gave up 
on it (like me).

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

nemesis wrote:
> Darren New escreveu:
>> nemesis wrote:
>>> a huge hate thread about Blender, 
>>
>> I find it funny that you're reading "hate" into any of the posts.
> 
> I find it funny that you don't notice it in-between the lines.

Maybe hatred of inanimate objects just isn't something I relate to.

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

Darren New escreveu:
> nemesis wrote:
>> Darren New escreveu:
>>> nemesis wrote:
>>>> a huge hate thread about Blender, 
>>>
>>> I find it funny that you're reading "hate" into any of the posts.
>>
>> I find it funny that you don't notice it in-between the lines.
> 
> Maybe hatred of inanimate objects just isn't something I relate to.

Maybe only people who love perfectly round surfaces can relate to. ;)

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

scott wrote:
>> This puzzles me. I'm not disputing you're wrong - usually there's some 
>> option to set the number of subsamples taken - but since a GPU can 
>> *only* draw straight lines, you'd think they could just use the 
>> closed-form formulas for doing mathematically perfect AA on polygon 
>> edges. It takes about 3 float-ops. No subsamples required.
> 
> That method has problems when you are drawing triangles adjacent to each 
> other.

Like what?

> Also how does your method work with a pixel shader?

If I actually knew what a pixel shader is, I could maybe answer. :-)

>> I still find it rather hard to believe that you can take a complex 
>> shape such as the surface of a water splash and automatically 
>> tesselate it.
> 
> If you're going for physical accuracy then your simulation data will be 
> in voxels or something anyway,

Unless it's a particle method.

> so using marching cubes or similar will get you your tesselated mesh directly.

I see.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

nemesis escreveu:
> Invisible escreveu:
>> I think because fundamentally I dislike trickery. Modelling solid 
>> objects as true solids with a real inside and outside, and real 
>> curves, and real patterns, etc. seems so much superior to faking it 
>> with lots of straight lines and pixels.
> 
> Fine, give us your perfectly curved SDL phone and we'll all agree with 
> you.  I'll give you the benefit of doubt and more 10 minutes.

I take it you can't prove your arguments, right?  Or perhaps you need a 
whole day to provide a pure SDL, perfectly curved phone?

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

>> Fine, give us your perfectly curved SDL phone and we'll all agree with 
>> you.  I'll give you the benefit of doubt and more 10 minutes.
> 
> I take it you can't prove your arguments, right?  Or perhaps you need a 
> whole day to provide a pure SDL, perfectly curved phone?

For your benefit, I will repeat myself: *most* man-made objects have 
lots of straight or simply-curved edges and are very easy to model with 
CSG. However, highly-curved non-random objects such as car bodies or 
trainers or similar are difficult to model using only CSG.

Then again, given that I personally can't model them with triangles 
either, it's kind of moot at this point.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 escreveu:
>>> Fine, give us your perfectly curved SDL phone and we'll all agree 
>>> with you.  I'll give you the benefit of doubt and more 10 minutes.
>>
>> I take it you can't prove your arguments, right?  Or perhaps you need 
>> a whole day to provide a pure SDL, perfectly curved phone?
> 
> For your benefit, I will repeat myself: *most* man-made objects have 
> lots of straight or simply-curved edges and are very easy to model with 
> CSG.

No, they aren't easy.  Which is why you're backing off.

> Then again, given that I personally can't model them with triangles 
> either, it's kind of moot at this point.

You can't because you're stubborn and does not listen to advice, but 
other people can because they learn instead of whine.

Bevels in Blender go about as easily as selecting the appropriate 
modifier from a drop-down list.  How many clever lines of SDL code do 
you have to go through to add perfectly curved bevels to your hard-edged 
CSGs?  don't mind, it's rhethoric.  You could ask clipka, because his 
train was the best piece of beveled pure CSG I've ever seen...

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

>>> I take it you can't prove your arguments, right?  Or perhaps you need 
>>> a whole day to provide a pure SDL, perfectly curved phone?
>>
>> For your benefit, I will repeat myself: *most* man-made objects have 
>> lots of straight or simply-curved edges and are very easy to model 
>> with CSG.
> 
> No, they aren't easy.  Which is why you're backing off.

So you're seriously telling me that if you wanted to model, say, an 
engine, you'd actually draw billions of triangles rather than just take 
a cube and intersect a few cylinders out of it, and then make the 
pistons to go in it, etc?

Um, why?

>> Then again, given that I personally can't model them with triangles 
>> either, it's kind of moot at this point.
> 
> You can't because you're stubborn and does not listen to advice, but 
> other people can because they learn instead of whine.

Or rather, because they've spent more time reading the documentation 
than I have so far?

> Bevels in Blender go about as easily as selecting the appropriate 
> modifier from a drop-down list.

I'll believe it when I see it. :-P

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 escreveu:
> So you're seriously telling me that if you wanted to model, say, an 
> engine, you'd actually draw billions of triangles rather than just take 
> a cube and intersect a few cylinders out of it, and then make the 
> pistons to go in it, etc?

Stop talking BS, dude.  If that's a challenge, post the SDL produced 
image and ask me to produce a Blender equivalent.  There are cubes and 
cylinders shapes available in Blender too, the rest, like curve 
smoothness, is all by means of modifiers.

I don't deal with the millions of polygons generated at render time by 
these modifiers, just with the simple cage meshes.  Are you listening 
this time or still playing deaf?

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

Darren New wrote:
> scott wrote:
>>>> right mouse button click (RMB) - selects
>>>> left mouse button click (LMB) - changes location of 3D cursor
>>>
>>> And I think that there pretty much sums up why people think Blender's 
>>> interface sucks. :-)
>>
>> Not really, you can change that one around (as I always do). 
> 
> Which is irrelevant to the point that it defaults to doing everything 
> differently than every other piece of software and platform, and you 
> have to read lots of manuals just to learn how to close the program.

Like going "File -> Quit Blender"?  Or just hitting the window x button? 
  Like in every other GUI app?

gee, stop man.  You showed before you can't even follow the Help manual 
entries that come with the app... it's not the app's fault that you guys 
choose it as a relief from your daily frustrations...

Post a reply to this message

nemesis wrote:
> Like going "File -> Quit Blender"?  Or just hitting the window x button? 
>  Like in every other GUI app?

OK, I'll grant that one was a bad example. :-)

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
>
> You can't because you're stubborn and does not listen to advice, but
> other people can because they learn instead of whine.
>
> Bevels in Blender go about as easily as selecting the appropriate
> modifier from a drop-down list.  How many clever lines of SDL code do
> you have to go through to add perfectly curved bevels to your hard-edged
> CSGs?  don't mind, it's rhethoric.  You could ask clipka, because his
> train was the best piece of beveled pure CSG I've ever seen...
>


I tried a project in blender and ultimately failed.  I was trying to make a
moving cross section through an (electronics) object that is essentially a board
with regular spacings of nails in it.  I wanted to use 2-tone B&W image as the
input device. I was able to get this to go in povray, after trying about a month
failing in blender.  I wanted the cross section to slice both the "nails" and
the "board".  Blender's CSG couldn't do the boolean logic on something this
complex. Povray didn't blink.

Post a reply to this message

gregjohn wrote:
> Blender's CSG couldn't do the boolean logic on something this
> complex. Povray didn't blink.

I think all problems I ran into with Blender were of the form "we didn't 
ever need to do this, so we didn't implement it."

For example, it seems to bomb if you move the container the fluid is in, 
crashing out the calculations for the fluid sim.

Or using Python for cloning an object and moving it so you have a whole 
bunch of them. Which works fine until you tell it to animate them, at which 
point it forgets where you placed them.

Stuff like that I'm just not going to battle against, because it shows 
there's underlying flaws in the deepest structures used by the program.

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

"gregjohn" <pte### [at] yahoocom> wrote:
> I tried a project in blender and ultimately failed.  I was trying to make a
> moving cross section through an (electronics) object that is essentially a board
> with regular spacings of nails in it.  I wanted to use 2-tone B&W image as the
> input device. I was able to get this to go in povray, after trying about a month
> failing in blender.  I wanted the cross section to slice both the "nails" and
> the "board".  Blender's CSG couldn't do the boolean logic on something this
> complex. Povray didn't blink.

It's not CSG.  They are messy boolean operations on meshes rather than solids.

would you show me the B&W image?

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:
> "gregjohn" <pte### [at] yahoocom> wrote:
> > I tried a project in blender and ultimately failed.  I was trying to make a
> > moving cross section through an (electronics) object that is essentially a board
> > with regular spacings of nails in it.  I wanted to use 2-tone B&W image as the
> > input device. I was able to get this to go in povray, after trying about a month
> > failing in blender.  I wanted the cross section to slice both the "nails" and
> > the "board".  Blender's CSG couldn't do the boolean logic on something this
> > complex. Povray didn't blink.
>
> It's not CSG.  They are messy boolean operations on meshes rather than solids.
>
> would you show me the B&W image?

Thinking a bit more about it, you'd probably have more luck getting that image
into some vector format like SVG and importing that into Blender:  no messy
boolean to cut out anything, it creates a nice mesh out of it.  Easy peasy.

Post a reply to this message

>> That method has problems when you are drawing triangles adjacent to each 
>> other.
>
> Like what?

Well draw your first filled triangle with your algorithm, and down the edges 
I presume most pixels will have some fractional coverage.  So if the 
coverage for a particular pixel is say 25%, I assume you take 25% of the 
triangle colour and blend it with 75% of the existing background colour. 
All looks very nice and perfectly AA'd.

Now draw the next one that is supposed to share one of the edges as the 
first triangle, this time that one particular pixel will have 75% coverage, 
so you take 75% of the triangle colour and 25% of the background colour 
(which is actually 75% of the original background and 25% of the first 
triangle).  Oops - the background will be showing through along the edge.

I guess you could get around it by only doing the AA algorithm on edges that 
aren't shared (after the back-face cull step), but typically the graphics 
card doesn't know this information while it's rendering.

>> Also how does your method work with a pixel shader?
>
> If I actually knew what a pixel shader is, I could maybe answer. :-)

The pixel shader is the code that gets called on the GPU to calculate the 
pixel value.  It will be passed various bits of information like the world 
coordinates, screen coordinates, lighting vectors etc.  Should the GPU still 
pass the coordinates of the *centre* of the pixel, even if only 25% of one 
corner is actually being covered?  Or is it more correct to pass the 
coordinates of the centre of the sub-pixel area that is being shaded?  IDK.

> Unless it's a particle method.

You mean to be rendered as a fluid?  You can't just raytrace particles 
directly either, you need some algorithm to make it look like a fluid.  I 
suspect algorithms exist for raytracing particles as a fluid (blobs?) and 
also for creating meshes from particles.  Anyway, people don't place the 
triangles by hand.

Post a reply to this message

> Yeah. In that case you'd have to use a sphere-sweep [which is inexplicably 
> slow for no defined reason].

And how many points would you put in the spline that your sphere-sweep was 
following?

>> But how to do the rounded edge then?  Matching up a round with the 
>> vertical sides (actually they're slightly off-vertical) of the button 
>> with the curved top surface doesn't sound very easy to me.
>
> It does to me, but hey...

Ermmm, ok, here's my button then, show me how to add a round and/or bevel to 
the top (+y) of it:

difference
{
 cone{ <0,0,0> 8 <0,5,0> 7}
 sphere{ <0,50,0> 46 }
 scale <1,1,0.75>
}

> Yes, because crude approximations

Who said anything about crude?  You said a billion triangles, on a 1920x1200 
screen that makes each triangle about 1/500th of a pixel.

> to cylindrical columns look so much more photo-realistic than actually 
> cylindrical columns. Oh, wait...

I've never seen a mathematically perfect cylindrical column IRL before.

> Ah, well, presumably if you're doing CAD rather than just pretty pictures, 
> you have *real* modelling tools. ;-)

True, but even when making pretty pictures (eg for films or posters etc) you 
don't want broken reflections like that - they look ugly.

Post a reply to this message

> So you're seriously telling me that if you wanted to model, say, an 
> engine, you'd actually draw billions of triangles rather than just take a 
> cube and intersect a few cylinders out of it, and then make the pistons to 
> go in it, etc?
>
> Um, why?

In your mind it seems everything is *way* simpler than it actually is in 
real life.  You think that an engine can be modelled by a few CSG 
operations, or a phone base or computer monitor.  Sure, you can get some 
very crude 3D model that way, but it will look awful.

Real life doens't have perfectly sharp edges or perfectly straight 
cylinders, real life has rounds on every single edge and lots of curved 
surfaces.  If you don't get the rounds and curved surfaces it is going to 
look rubbish in any render.

Here's a real life engine for you (I assume you meant car engine):

http://www.ausmotive.com/images/BMW-335-engine-01.jpg

Are you really telling me you could get a half-way realistic SDL version of 
that in a reasonable time?

Post a reply to this message

>>> That method has problems when you are drawing triangles adjacent to 
>>> each other.
>>
>> Like what?
> 
> Well draw your first filled triangle with your algorithm, and down the 
> edges I presume most pixels will have some fractional coverage.  So if 
> the coverage for a particular pixel is say 25%, I assume you take 25% of 
> the triangle colour and blend it with 75% of the existing background 
> colour. All looks very nice and perfectly AA'd.

Well, presumably you'd need an alpha channel. Otherwise any further 
drawing to these partially-covered pixels won't look right...?

>>> Also how does your method work with a pixel shader?
>>
>> If I actually knew what a pixel shader is, I could maybe answer. :-)
> 
> The pixel shader is the code that gets called on the GPU to calculate 
> the pixel value.  It will be passed various bits of information like the 
> world coordinates, screen coordinates, lighting vectors etc.

Interesting. I didn't know that. Last time I looked, the GPU takes a 
polygon, and optionally a texture, optionally does some point-light 
calculations, and draws a textured polygon according to the current 
camera position. The textures are usually MIP-mapped - in other words, 
AA precomputed - so that only leaves the polygon edges to worry about.

> Should the 
> GPU still pass the coordinates of the *centre* of the pixel, even if 
> only 25% of one corner is actually being covered?  Or is it more correct 
> to pass the coordinates of the centre of the sub-pixel area that is 
> being shaded?  IDK.

If I had to take a guess, I'd say pretend that the polygon extends to 
infinity in all directions, run the shader as usual, and then just 
adjust the alpha channel according to polygon coverage. (IOW, yes, the 
center of the screen pixel.) OTOH, I haven't actually tried it to see 
what it looks like...

>> Unless it's a particle method.
> 
> You mean to be rendered as a fluid?  You can't just raytrace particles 
> directly either, you need some algorithm to make it look like a fluid.  
> I suspect algorithms exist for raytracing particles as a fluid (blobs?) 
> and also for creating meshes from particles.  Anyway, people don't place 
> the triangles by hand.

Yeah, if you use particles you need to somehow construct a surface from 
the particle positions. But saying "all points within K units of a 
particle are designed as inside" is much easier than trying to determine 
the curvature of a complex shape and tesselate it with just the right 
number of triangles...

But hey, what do I know? Apparently nothing.

Post a reply to this message

scott wrote:

> In your mind it seems everything is *way* simpler than it actually is in 
> real life.  You think that an engine can be modelled by a few CSG 
> operations, or a phone base or computer monitor.  Sure, you can get some 
> very crude 3D model that way, but it will look awful.
> 
> Real life doens't have perfectly sharp edges or perfectly straight 
> cylinders, real life has rounds on every single edge and lots of curved 
> surfaces.  If you don't get the rounds and curved surfaces it is going 
> to look rubbish in any render.
> 
> Here's a real life engine for you (I assume you meant car engine):
> 
> http://www.ausmotive.com/images/BMW-335-engine-01.jpg
> 
> Are you really telling me you could get a half-way realistic SDL version 
> of that in a reasonable time?

If you want to model every individual surface and line right down to the 
engine number stamped on the side, surely it's going to take a ludicrous 
amount of time no matter what tool you use.

I think if you sat down and spent enough time on it, it's quite 
plausible you could eventually model something like this. The pipework 
would be somewhat tricky, and it's not fantastically easy to model an 
intricate object with a single photo from just one angle, but I think it 
should be doable.

Of course, almost *anything* is possible given a mathematically 
unbounded amount of time, so maybe the interesting question is how long 
it would take with a simple mesh modeller?

Post a reply to this message

scott wrote:

> Here's a real life engine for you (I assume you meant car engine):
> 
> http://www.ausmotive.com/images/BMW-335-engine-01.jpg

Interesting thought: This is a modern car engine. It was almost 
certainly designed using a computer. I wander which modelling technology 
*they* used to design it in the first place?

Post a reply to this message

> Well, presumably you'd need an alpha channel. Otherwise any further 
> drawing to these partially-covered pixels won't look right...?

I don't understand how having an alpha channel would help?  Can you explain 
how it would solve the background-showing-through-the-joins problem?

> Interesting. I didn't know that. Last time I looked, the GPU takes a 
> polygon, and optionally a texture, optionally does some point-light 
> calculations, and draws a textured polygon according to the current camera 
> position. The textures are usually MIP-mapped - in other words, AA 
> precomputed - so that only leaves the polygon edges to worry about.

That *was* how GPUs worked, but since DirectX 8 there have been programmable 
pipelines, and since DirectX9 you've been forced to use them.

Your CPU program throws a load of vertices (a "mesh") at the GPU once.  Then 
every frame *your* GPU vertex shader program transforms those vertices into 
screen space using whatever algorithm you want (usually your CPU app would 
have prepared a 4x4 matrix in advance).  This GPU program can also "output" 
any other variables it likes, common ones are normal vectors, texture 
coordinates etc.  The GPU then takes this bunch of "output" data at each 
vertex and interpolates it across the triangle, pixel by pixel.  For each 
pixel it runs *your* pixel shader program with the interpolated data as the 
input.  It's completely up to you what you do in the pixel shader, commonly 
you use the interpolated texture coordinates to look up a colour from a 
texture, combine it with some lighting calculation, and return that. 
Whatever you return the GPU writes to the frame buffer.

> If I had to take a guess, I'd say pretend that the polygon extends to 
> infinity in all directions, run the shader as usual, and then just adjust 
> the alpha channel according to polygon coverage. (IOW, yes, the center of 
> the screen pixel.) OTOH, I haven't actually tried it to see what it looks 
> like...

What if you have a texture that is thin red/blue stripes (or any other 
detail)?  That method would likely pick the wrong colour if only a small 
portion of the pixel was actually visible.  Still I guess it's minor error, 
but one that multi-sampling would get right.

> Yeah, if you use particles you need to somehow construct a surface from 
> the particle positions. But saying "all points within K units of a 
> particle are designed as inside" is much easier than trying to determine 
> the curvature of a complex shape and tesselate it with just the right 
> number of triangles...

You could just use marching cubes, you don't even need to pre-calculate 
anything, when you come to each vertex of each cube just use the distance to 
the nearest particle minus K as the value.

BTW that isn't a very good way of making a fluid from particles, it's just 
going to look like a lump of spheres glued together.

Post a reply to this message

>> Well, presumably you'd need an alpha channel. Otherwise any further 
>> drawing to these partially-covered pixels won't look right...?
> 
> I don't understand how having an alpha channel would help?  Can you 
> explain how it would solve the background-showing-through-the-joins 
> problem?

Supposing that polygon A is red, polygon B is green, and the background 
is blue, the single pixel where the two edges intersect should 
presumably by drawn with nonzero values for all three channels.

The way I imagine it working is that when polygon A is drawn, the 
pixel's RGB data is set to pure red, and the alpha value is set 
according to pixel coverage. Then, when polygon B is drawn, the green is 
mixed in according to the pixel's current alpha value. The alpha of the 
new polygon is then added to the existing alpha. When all polygons have 
been drawn, the final alpha value is used to mix in the background.

At least, I presume that's how you'd do it...

> That *was* how GPUs worked, but since DirectX 8 there have been 
> programmable pipelines, and since DirectX9 you've been forced to use them.
> 
> Your CPU program throws a load of vertices (a "mesh") at the GPU once.  
> Then every frame *your* GPU vertex shader program transforms those 
> vertices into screen space using whatever algorithm you want (usually 
> your CPU app would have prepared a 4x4 matrix in advance).  This GPU 
> program can also "output" any other variables it likes, common ones are 
> normal vectors, texture coordinates etc.  The GPU then takes this bunch 
> of "output" data at each vertex and interpolates it across the triangle, 
> pixel by pixel.  For each pixel it runs *your* pixel shader program with 
> the interpolated data as the input.  It's completely up to you what you 
> do in the pixel shader, commonly you use the interpolated texture 
> coordinates to look up a colour from a texture, combine it with some 
> lighting calculation, and return that. Whatever you return the GPU 
> writes to the frame buffer.

Finally, an explanation of programmable GPUs that ACTUALLY MAKES SENSE. 
Thanks for that.

>> If I had to take a guess, I'd say pretend that the polygon extends to 
>> infinity in all directions, run the shader as usual, and then just 
>> adjust the alpha channel according to polygon coverage.
> 
> What if you have a texture that is thin red/blue stripes (or any other 
> detail)?  That method would likely pick the wrong colour if only a small 
> portion of the pixel was actually visible.  Still I guess it's minor 
> error, but one that multi-sampling would get right.

True I guess...

>> Yeah, if you use particles you need to somehow construct a surface 
>> from the particle positions.
> 
> You could just use marching cubes, you don't even need to pre-calculate 
> anything, when you come to each vertex of each cube just use the 
> distance to the nearest particle minus K as the value.

Mmm, interesting. I wonder if that actually works?

> BTW that isn't a very good way of making a fluid from particles, it's 
> just going to look like a lump of spheres glued together.

Well, no. You'd want to smooth it somehow, without slowing the 
computation to the speed of molasses...

Post a reply to this message

> I think if you sat down and spent enough time on it, it's quite plausible 
> you could eventually model something like this. The pipework would be 
> somewhat tricky, and it's not fantastically easy to model an intricate 
> object with a single photo from just one angle, but I think it should be 
> doable.
>
> Of course, almost *anything* is possible given a mathematically unbounded 
> amount of time, so maybe the interesting question is how long it would 
> take with a simple mesh modeller?

Not as long as with SDL :-)

Why don't you post a link to a photo of something that you think you could 
easily create a realistic model of in SDL?

> Interesting thought: This is a modern car engine. It was almost certainly 
> designed using a computer. I wander which modelling technology *they* used 
> to design it in the first place?

A high-end 3D CAD system, probably Catia as BMW use that for most other 
things in the car.

Nice video of it being used:

http://www.youtube.com/watch?v=80-JcXO5Mi8

Post a reply to this message

> Then, when polygon B is drawn, the green is mixed in according to the 
> pixel's current alpha value. The alpha of the new polygon is then added to 
> the existing alpha. When all polygons have been drawn, the final alpha 
> value is used to mix in the background.

The "background" is not some fixed bitmap though, the "background" is just 
whatever happens to be behind the triangle you are drawing, probably another 
triangle, which has another triangle behind it, etc.  Your method requires 
you to store a "background" framebuffer for every group of joined triangles 
that are to be rendered.  Anyway, the graphics card doesn't know which 
triangles are meant to be joined, it just chugs through a huge list of 
triangles, how is it going to know when to pause and do the alpha mixing 
stage?

> Well, no. You'd want to smooth it somehow, without slowing the computation 
> to the speed of molasses...

Yeh you need something like an isosurface, where the "strength" is somehow 
related to the distance to neighbouring particles.  Is relatively easy to 
both raytrace this directly or create a mesh from.

Post a reply to this message

scott wrote:
> I've never seen a mathematically perfect cylindrical column IRL before.

http://www.sizes.com/units/kilogram.htm

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

>> Yes, because crude approximations
> 
> Who said anything about crude?  You said a billion triangles, on a 
> 1920x1200 screen that makes each triangle about 1/500th of a pixel.

Fundamentally, what it comes down to is this: No matter how smooth it 
looks, *I* would know it's fake. And that would seriously annoy me.

Why have a fake when you can have the real thing?

>> to cylindrical columns look so much more photo-realistic than actually 
>> cylindrical columns. Oh, wait...
> 
> I've never seen a mathematically perfect cylindrical column IRL before.

And I've never seen a cylinder make of triangular facets IRL either.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> Fundamentally, what it comes down to is this: No matter how smooth it 
> looks, *I* would know it's fake. And that would seriously annoy me.

So pixels bug you, huh?

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

Orchid XP v8 escreveu:
>>> Yes, because crude approximations
>>
>> Who said anything about crude?  You said a billion triangles, on a 
>> 1920x1200 screen that makes each triangle about 1/500th of a pixel.
> 
> Fundamentally, what it comes down to is this: No matter how smooth it 
> looks, *I* would know it's fake. And that would seriously annoy me.

doesn't it bother you then that computers math operations use fake real 
numbers?  It's all fake.  I don't mind if it doesn't show.

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

nemesis wrote:

> doesn't it bother you then that computers math operations use fake real 
> numbers?

The fact that they're fake doesn't bother me.

The fact that it's a non-associative algebra is a little disturbing 
though... o_O

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>> Fundamentally, what it comes down to is this: No matter how smooth it 
>> looks, *I* would know it's fake. And that would seriously annoy me.
> 
> So pixels bug you, huh?

Well... given the choice, I am a vector graphics kind of guy. ;-)

I haven't yet come up with a ray to raytrace something and come up with 
a vector description though. I'm guessing this is highly, *highly* 
intractable.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:
> 
>   Does everything have to have a reason behind it? 

Yes.

> Can't things be done just
> for the fun of it?
> 

Isn't that a valid reason?

-Aero

Post a reply to this message

Eero Ahonen <aer### [at] removethiszbxtnetinvalid> wrote:
> Warp wrote:
> > 
> >   Does everything have to have a reason behind it? 

> Yes.

> > Can't things be done just
> > for the fun of it?
> > 

> Isn't that a valid reason?

  Reason implies logic. Fun doesn't always involve logic.

-- 
                                                          - Warp

Post a reply to this message

On Fri, 18 Dec 2009 20:54:06 -0500, Warp wrote:

> Eero Ahonen <aer### [at] removethiszbxtnetinvalid> wrote:
>> Warp wrote:
>> > 
>> >   Does everything have to have a reason behind it?
> 
>> Yes.
> 
>> > Can't things be done just
>> > for the fun of it?
>> > 
>> > 
>> Isn't that a valid reason?
> 
>   Reason implies logic. Fun doesn't always involve logic.

It's also not mutually exclusive.

Jim

Post a reply to this message

Warp wrote:
> 
>   Reason implies logic. Fun doesn't always involve logic.
> 

Yes. Doing X because of Y makes Y the reason to do X - that certainly is
logical :). IMO fun is universally a valid value for Y as long as no-one
gets hurt.

Or have I misunderstood the meaning of the word "reason"?

-Aero

Post a reply to this message

On 12/18/09 19:54, Warp wrote:
> Eero Ahonen<aer### [at] removethiszbxtnetinvalid>  wrote:
>> Warp wrote:
>>>    Does everything have to have a reason behind it?
>
>> Yes.
>
>>> Can't things be done just
>>> for the fun of it?
>>>
>
>> Isn't that a valid reason?
>
>    Reason implies logic. Fun doesn't always involve logic.

	But doing something for fun is usually logical.

-- 
Depend on the rabbit's foot if you will, but remember, it didn't help 
the rabbit.

Post a reply to this message

Eero Ahonen <aer### [at] removethiszbxtnetinvalid> wrote:
> Or have I misunderstood the meaning of the word "reason"?

  I was playing with the two distinct meanings of the word.

-- 
                                                          - Warp

Post a reply to this message

>> I thought all games used per-pixel lighting now?
>
> Apparently HL2 doesn't. (They've upgraded the Source engine several times 
> since then, so maybe it does now. I doubt it.)

HL2 has normal mapping, so it definitely does use per-pixel lighting, at 
least on some surfaces. It samples from three lightmaps representing the 
light coming from three directions, and then does dot products with the 
normal to determine the total light on a pixel.

Characters do something similar but without light maps.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

Slime <fak### [at] emailaddress> wrote:
> >> I thought all games used per-pixel lighting now?
> >
> > Apparently HL2 doesn't. (They've upgraded the Source engine several times 
> > since then, so maybe it does now. I doubt it.)

> HL2 has normal mapping, so it definitely does use per-pixel lighting, at 
> least on some surfaces. It samples from three lightmaps representing the 
> light coming from three directions, and then does dot products with the 
> normal to determine the total light on a pixel.

> Characters do something similar but without light maps.

  I think it all comes down to how you *define* "per-pixel lighting".

  In the good old days gouraud shading was the standard because it was
inexpensive, as opposed to phong shading which was (at the time of
software renderers and even with the early 3D graphics acceleration cards)
very heavy, as it required calculating lighting on each pixel, as opposed
to gouraud shading, where it was enough to calculate it only on each vertex
point (but naturally the result was not even nearly as good).

  (Basically gouraud shading is calculating accurate lighting at the three
vertices of a triangle and then interpolating these lighting values linearly
throughout the surface of the triangle. Linear interpolation is inexpensive,
especially with early acceleration cards. Full-fledged phong-shading requires
making accurate lighting calculations on every single pixel, which was very
heavy at the time.)

  So you could say that phong-sading is per-pixel lighting.

  On the other hand, nowadays when people talk about "per-pixel lighting"
in conjunction with 3D graphics acceleration cards, what they are really
talking about is per-pixel shaders (usually as opposed to lightmapping
and/or vertex shaders).

-- 
                                                          - Warp

Post a reply to this message