normal maps
category: general [glöplog]
I'm assuming Gargaj means that the CSG algorithm does not actually generate a new object (ie. vertices and faces), it merely renders the CSG results. And that's why he labels it 'fake'.
(I'm happy I spent 50 dollars on those interpretive reading courses)
(I'm happy I spent 50 dollars on those interpretive reading courses)
aaaaaand the referee signals, yes, now it's official: 1-0 for sagacity!
In that case Gargaj is working from the wrong assumption. CSG is in no way related directly to vertices and faces anyway. Vertices and faces are just one possible representation of a resulting CSG object (and as stated before, not always a very handy one).
So perhaps the 'fake' label was a tad wrong?
So perhaps the 'fake' label was a tad wrong?
Also, I was referring to the "something like that"-comment, not the production of new objects, but the visualization of the results. Are the visualizations significantly different?
what's the point of csg for visualizing only?
the point is that if you don't want to stick to operations with primitves, you have to tesselate the object into vertices and faces eventually.
the point is that if you don't want to stick to operations with primitves, you have to tesselate the object into vertices and faces eventually.
I think you are stuck too much in your own world.
Firstly, why do you 'have to tesselate' the objects eventually? Obviously for a raytracer there would be no point at all. And if you use 3d acceleration, does it matter if you tesselate first, or just show the object directly, as long as the object can be shown?
As I already mentioned, it's an advantage not having to tesselate the resulting objects, when you are modifying the object in realtime.
And as I already mentioned, this routine is for CAD software. The result of CAD software is not a mesh of triangles, but a recipe for manufacturing a real-life object. In our case it's a list of holes to drill. CSG is an easy way to visualize and inspect these holes in realtime, and the SCS algo is superior to raytracing in terms of speed, in this case. We do NOT have to tesselate the object, EVER (vertices and faces have no meaning to us), and doing so would severely reduce the speed and therefore interactivity of our program.
Firstly, why do you 'have to tesselate' the objects eventually? Obviously for a raytracer there would be no point at all. And if you use 3d acceleration, does it matter if you tesselate first, or just show the object directly, as long as the object can be shown?
As I already mentioned, it's an advantage not having to tesselate the resulting objects, when you are modifying the object in realtime.
And as I already mentioned, this routine is for CAD software. The result of CAD software is not a mesh of triangles, but a recipe for manufacturing a real-life object. In our case it's a list of holes to drill. CSG is an easy way to visualize and inspect these holes in realtime, and the SCS algo is superior to raytracing in terms of speed, in this case. We do NOT have to tesselate the object, EVER (vertices and faces have no meaning to us), and doing so would severely reduce the speed and therefore interactivity of our program.
Oh, and Gargaj, this should be obvious.
how many users of CAD software use Geforce FX 5200 cards?
CAD is a very big market, not all of them uses the most fancy hw there is. Acctualy, most doesn't.
my oh my... how much shit every post of mine produces after being swallowed by Scali. :)))))
This is starting to get funny :)
And it only took three pages!
let's discuss the DCS algo now ;)
Yea, it's quite funny how ignorant people like eye, plek and gargaj are.
thanks.
seems like i'm the one not getting the point of "the point is that if you don't want to stick to operations with primitves".
seems like i'm the one not getting the point of "the point is that if you don't want to stick to operations with primitves".
Indeed you don't. You made it out to be a requirement of CSG that it should generate new geometry, or else the CSG would be 'fake'. You also didn't realize that sometimes the visualization itself is important, and not the geometry.
Clear signs of ignorance, if you ask me.
Clear signs of ignorance, if you ask me.
Acctually its quite funny to see Scali with his very limited ways of expressing himself kicking butt in here.. But ofcourse, it doesnt say much about him, just about the other ones here ;-)
if i do. but i don't :D
my point is as long as you use primitives, you're ok.
but try to visualize something like "object a + object b - object c .... + meshsmooth".
changes in the euler-characteristics of the surface can drastically change the output of a certain effect/modifier chain.
well ok, CAD programs don't do meshsmooth since they only stick to abstract geometry, that's true. but who mentioned CAD on the first place?
my point is as long as you use primitives, you're ok.
but try to visualize something like "object a + object b - object c .... + meshsmooth".
changes in the euler-characteristics of the surface can drastically change the output of a certain effect/modifier chain.
well ok, CAD programs don't do meshsmooth since they only stick to abstract geometry, that's true. but who mentioned CAD on the first place?
Who mentioned meshsmooth?
What's your point anyway?
You were wrong. Now you're just talking about completely other things.
Go do something useful, like figuring out how to envmap or something.
What's your point anyway?
You were wrong. Now you're just talking about completely other things.
Go do something useful, like figuring out how to envmap or something.
where did you see me go ranting about slow java demos here? :)
let's not try to be personal here.
my point is, *finally*, is that the SCS/Goldfeather method ONLY works in visualizing only, for actual mesh "generation" it doesn't. in THIS, we're both right. right?
let's not try to be personal here.
my point is, *finally*, is that the SCS/Goldfeather method ONLY works in visualizing only, for actual mesh "generation" it doesn't. in THIS, we're both right. right?
About Geforce FX 5200, it is a crap... some demos worked much better with my old GF2TI. But about PS2, don't you think it is about the screen resolution? I think PS2 renders in 640x480, and hardware demos try to use 1024x768, so it may be a fillrate thing.
a ps2 is faster in creating fake meshs from csg visualized things than a geforce fx 5200
Gargaj, still, CSG was iirc originaly NOT implemented on meshes, why should it? Its the most bitchiest way to make it... Even tho in a 64k editor you want it like that but has NOTHING to do with the technique, its like saying a color is an int, everything else is fake. because you have a 32bpp card and write VesaII stuff.