instinctive-blender 2 released (New Game engine soundsystem)

intrr · Post by **intrr** » Fri Dec 03, 2004 1:52 pm

I do understand why they have been removed - for the same reason as there's a CLIPPY in Office applications

Happy to make others happy and/or improve their work efficiency

bertram · Post by **bertram** » Sat Dec 04, 2004 12:49 am

The automatic removal of double vertices may lead to 'corrupt' meshes.
Example: Take the monkey and rotate the mesh in any angle. The UI says "Auto-Merged: 2". After this action, Suzanne has two holes under her eyes

This is because the eyeballs have each been merged with the whole head.
Maybe this automatism should check first if the vertices that could be merged belong to one single mesh or whether there are several loose parts within the mesh. If the vertices that may be merged belong to different loose parts the merger shouldn't be executed!

intrr · Post by **intrr** » Sat Dec 04, 2004 2:53 am

bertram: Interesting, this doesn't occur for me. It doesn't even try to remove vertices. I'm sure your Limit value is far too high. And if in doubt, you can turn this feature off easily

bertram · Post by **bertram** » Sat Dec 04, 2004 1:49 pm

it's the default value 0.001
Ah, just found where to switch it off.
Basically I find the routine of auto-removing double vertices a good idea. I just like to suggest a few optional checks before auto-removing.
One should be checking if the vertices have the same texture index assigned. And the more important should be the check whether the candidate vertices belong to the same loose part of a mesh (do all candidate vertices become selected at once when selecting one of them with L-key?)

intrr · Post by **intrr** » Sat Dec 04, 2004 8:04 pm

bertram: You're probably right. Should be checked on...

UPDATE: OSX Package available:

http://blender.instinctive.de/downloads/release/

intrr · Post by **intrr** » Sun Dec 05, 2004 6:44 pm

Just a note, shouldn't you have found out already: There's an issue with the network renderer: you have to pack the file manually (File->Pack Data) before hitting "ANIM" - if you don't do this, none of your external data (images, etc.) will be accessible on the render clients if they don't share the same path to the data.

I will fix it for the next version to auto-pack the data into the file (non-destructively).

bfvietnam · Post by **bfvietnam** » Mon Dec 06, 2004 12:18 am

best solution to removing doubel vertices is to not have them in the first place.. That is to make meshes from clouds over vertices.. Vertices make edges, edges make meshes.. In blender, meshes contain vertices and the edges are implicit.. That's the reason you have double vertices.. But the meshes can refer to vertices indirectly.. The problem is knowing which quads share edges.. You could do that by making the vertices into structures that have pointers that point back to the adjacent meshes..

As for disjoint meshes, its harder because the location of the vertices are represented with floats, not integers.. So there will be a certain amount of difference.. Try this, take a mesh, scale it down (while zooming in so you can see it), and keep scaling it down, until its a speck on your screen. Scale it back.. Some or all of the vertices will be merged together, because the floating point numbers are finite at small values, like .1 * .00001 might become .00000125..

I find this problem a lot on blender's UV texturing system.. If you scale a UV map down and scale it up, the vertices will be quantized, making the map look pixelated.

But its not a problem with blender so much as its a limitation of the
compute at that scale. The effect of auto-merging is no different than
this disturbing effect, and your computer will do it automatically.

If there was a way to assess the closeness of a percentage of the vertices, or to select meshes that should be merged, and merge meshes based on the preferred relationship, that would be easier to control than to have it done automatically, which would just be as disturbing as using an anti-lock brake system on an icey road. Anti-lock brakes kick in when the car determines the resistance of the road toward the tire, if there is a lack of control by the driver over the actions, the car's ABS system prevents the braking system and substitutes in something else to help the driver control the car. But if you are a stunt driver who wants the effect of slippage on ice or water to do a special kind of turn, then the ABS is completely useless, not to mention the gronking noises of the hydraulic system will make you think you are grinding gears.

So something that looks good to one, will be undesireable to another. I would make the feature of automatic vertex merging a toggle, not a permanent feature.. Unless you plan to fix the way blender stores data, which may help. I figure with the addition of edge-loops, this changed the underlying storage mechanism.

intrr · Post by **intrr** » Mon Dec 06, 2004 12:31 am

bfvietnam: The point of "Auto-merge" is to assist me in merging vertices, i.e. when I scale them down to 0 in one axis, so that it spares me the additional 'Remove doubles' step. That's pretty much all reason why I implemented it

bfvietnam · Post by **bfvietnam** » Mon Dec 06, 2004 12:35 am

intrr wrote:bfvietnam: The point of "Auto-merge" is to assist me in merging vertices, i.e. when I scale them down to 0 in one axis, so that it spares me the additional 'Remove doubles' step. That's pretty much all reason why I implemented it

Well if you do it in edit mode, it should be pretty automatic now,
because it reduces the numeric representation to nothing..

But why make it automatic?

I feel like I just jumped into a discussion, I probably should go back and
read the discussion.. It just sounded strange..

intrr · Post by **intrr** » Mon Dec 06, 2004 12:36 am

No, you just have to read what I write

I have added "Auto-Merge" because I wanted to spare the step of "Remove Doubles" after scaling something down to 0 in one axis for merging vertices there. Got the point now?

bertram · Post by **bertram** » Mon Dec 06, 2004 2:09 am

I liked the instinctive-N-panel a lot. Until I dragged the divider (default setup) to the middle of the screen to get access to the IPO window. The N-panel was moved along with the resizing of the viewports. BUT when I dragged back the divider to the max right the N-panel stayed in its position so there was no way accessing its header! No way bringing it back to its original position. Bad thing!

intrr · Post by **intrr** » Mon Dec 06, 2004 4:37 am

bertram: Yes, that's a bug. as a workaround, you can drag it by left-clicking *above* the panel and then dragging.

Will be fixed.

bfvietnam · Post by **bfvietnam** » Tue Dec 07, 2004 12:15 am

intrr wrote:No, you just have to read what I write

I have added "Auto-Merge" because I wanted to spare the step of "Remove Doubles" after scaling something down to 0 in one axis for merging vertices there. Got the point now?

Well if you scale down to 0 on one axis, its not as simple as merging vertices.. You could have overlapping polygons which would call for a check for intersection and retesselation of the object.. Take a icosphere (probably a poor example, maybe an asymmetric Monkey Head), scale it down to zero on some axis, I'm assuming there will be some overlapping polygons. Now what if some vertices directly overlap, wouldn't you have to take the union of the overlapping polygons and retesselate them so that
they don't occupy the same space (producing an ambiguous sort in the Z buffer comparison of the meshes, which looks like splittering wood in
a 16 bit Z buffer).

Another example, take two squares, take one and twist it around (so the left and right edges of the square make an X).. If you flatten the twisted against the regular square (assuming the vertices overlap), and merge their vertices, you will have four vertices, but 6 edges.. Another example, is just take two squares and flattening them, then merging the vertices, producing 4 edges, 4 vertices and two quads, or one?

You will have to detect holes in the mesh to determine how to retesselate the mesh when merging vertices.. Or you will have overlapping polygons, which is not beautiful in a rendering system that uses Z buffers.

Some functions that need to be implemented are where two polygons are
detected to be overlapping, where their edges intersect each other,
vertices must be define, so that the surfaces can be reduced from two
to one.. I guess you could reuse the boolean operation code for
finding the union of two overlapping quads, or this would need to be
in the boolean operation code (take a square, duplicate it, move it constrained to an axis within the same plane so both squares overlap and take the same space, take a union of the two squares, this should produce 3 rectangles.. if this doesn't work extrude the squares into cubes,
and try it again with the boolean union operation).

I'm saying, its possible that the boolean code for doing intersections, subtractions and unions can be reused here to handle the mesh intersection, and then merge the vertices (possibly already handled
by the boolean operation)..

bertram · Post by **bertram** » Tue Dec 07, 2004 1:04 am

bfvietnam: puh! that's very abstract....

intrr: The other thing I wanted to mention is that obviously the X-Sorting and the Hashing of Vertices doesn't work. At least there is no change in the build-effect. Am I missing something?

intrr · Post by **intrr** » Tue Dec 07, 2004 7:41 am

bertram: Yes, but that's the same as in the official Blender version, it's not specific to instinctive-blender.

I was surprised when I tried it a few days ago, too, but it behaves the same even in 2.25.

(It does work for particle effects, just not for build)