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