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