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