just a quick idea. It happens a lot that i have to wait for some operation in max. its shorter than rendering for 2 hours, but its way longer
for normal interaction with program. like lets say creating blob mesh, applying multires, substracting objects via booleans or subdivision.. or something like that. I have always task manager window opend and minimised in try bar,
so i see how much my processor is owerloaded. but I have to sit there and waite, staring at that small indicator, till I can finally move my mouse again. thats so annoying.
couldn’t we have a small beep? lets say max starts to use 100 cpu power, for longer then, dono, 20 s. our beeper program monitors this cpu usage. and after cpu usage for max goes down dono, 10 % lets say beeper still waits a bit to make sure its not a temporary
pose in cpu usage by max, and lets say after 5s. it beeps. meanwhile, user, has applied some heavy operation, and went to make cafe. and he doesn’t need to look at cpu usage indicator, all i care about
is my coffee, till i hear the beep.
i think it could be helpful, or? annoying? of course it should not be on by default, and user could turn it on only if he or she needs it…
So as we can see in a previous post (if we read comments) there where some concerns about my proposals validity. MainlyDelt0r raised some valid questions. therefore i have been struggling to improve my initial idea, and here is what i came up with. Now, its still has some flows. and questions. but its for u to judge, sins i have no clue about maths, and here its quite important, i mean the math.
so the idea is this.
A. we have a mesh. *(base mesh) which we will use to to determine where the “blobs” appear.
B. we will get the normals of each vertex.
c. then the slicing planes should be generated. (here u can look at my old post or drawings beneath)
here comes the first problem. what i want to find out – is there a way to limit this “slice plane’s ” effect. here no one will understand me, so lets have a look at the picture:
Here we have a blob mesh, and a slice tool. the white plane is a slice plane, and green line is outline which is generated. the problem is that the green outline goes out of boundaries of slice plane, and correct me if iam wrong but iam sure algorithm behind this procedure works this way. so what we would like to have here would look like this:
Ok how to do it ? i have no clue. It might require rewriting all algorithms behind this operation, or doing it old way, and then subtracting unneeded parts. which is probably easier.
so now lets imagine our slicing works like we want it, and lets move on.
so in order to understand my “hand” drawings here is another diagram for explanation:
so this diagram shows a mesh we will be thinking about. in next drawings i draw only 3 vertexis out of this mesh. In this image we can also see averaged normals (left)cos normally each plane is plane :) so all 4 vertexies should like in image on right. but we can get average values.
you can enlarge this image to see better. but the idea is to make planes for each vertex separately.
so here as well we have problems. first of all we would want to arrange planes so the would make a “continuity” i mean they would go like this: /\/\/\/\/\/\ shit i have no idea how to explane…. look at the drawings again. chm…. please tell me if anyone understands what i am talking about ? ah? anyone?
so and last step would be to “weld” vertexies who are very close to each other.
again i wonder how easy it would be to make so many “restricted” planes for slicing.
but from what i understand, if it would work it could improve mesh topology or?
ok, its a long time. so some thoughts on implicit surfaces and their topology. so why do we talk about it in first place, its becouse of its ugly topology. metaballs are so cool, but hardly usable in animations and in other fields cos of irregular and ever chaging mesh topology, so what do we do? lets think.
first, a description of implicit surface as i understand it.
2.2.3 Implicit surfaces (Bloomenthal 1987)
Implicit surfaces are also known as “Metaballs”, “Blobbies” or “Soft objects”.
Implicit surface is a technique first introduced by Jim Blinn in 1980. The idea is to have control objects, which determine the resulting surface. Each control object generates a sphere around itself. When two or more controller objects are close together, the resulting surface will “melt” together. So instead of two spheres one will have two spheres which are connected and form a “blobby” single surface shape. How much the resulting surfaces blob together is a result of distances from controlling objects and of weights of these control objects. (Maestri. 1999 43-44)
so i had few ideas on the matter. pls look at a picture and tell me what u think.
ok. now as far as i understand the poligonization of such mathematical substance :) as metaball, it works like this (and pls correct me if i am wrong) the algorithm “checks” certain points in worldspace to see if that point is in or outside of this mathematical descriptio0n of metaballsurface. so basically, user determines “resolution” or level of detail he or she wants, and based on that, algorithm generates planes, to see where are boundaroes of this object in that particular plane. and planes are generated in x, y, and z. so pls look at picture beneath. so what i thought of is, why user is not able to determine how these planes are distributed and aligned? why dont we have such simple control as in uv ordinates, u know we would choose box, cilinder, sphere just like in uv layout (imagine box uv layout as a traditional plane distribution for imlicitsurfaces).
so people who have read, and understood, some of papers about implicit surfaces, including old john blinns texts, tell me do i bulshit or that could be a very small step towards better topology?
While getting bigger some parts of trees tend to connect in between and become as one part. It is very likely to happened in a base of trunk and in root level under earth. Sometimes it happens to the double trunks. Some trees are goring as two, and become as one. This feature might be not so relevant for realistic trees, but it sure is a good addition to more interesting and artistically more “advanced” trees.
Possible meatballusage in tree trunk generation
Another possible way of tree trunk detalization could possibly be done by meatballs usage in the trunk surface generation.
In most of current day available 3d packages, metabals (aka: inplicit surfaces blob mesh) are common modeling technique. Also, we are not limited by using metabals, as a controllers for newly created “blobby” looking mesh, but we also can use already made 3d model – which would act as a matrix of metabals. Usually metabal creation tool would interpret each vertex of the model as a controlling metabal, and in such way we would use reference model of lower 3d detail, to create metaball surface.
edges of hole in blobmesh
roots with blobmesh.
top row shows edges and polygons. 1 input mesh, 2 blobmesh 3 multires (mesh optimization) 4 meshsmooth (subdivision surface)
If we would take our generated tree trunk surface, and use it as a reference model for metabals creation, we would achieve automatic metalization, of surface which would follow general surface outlines. The ideal solution would be to get easy control over each metaballs threshold values. usually metaball tools lets us to set threshold values only to all set of metabals, and restrict us of having different values for each metabal. it would be very beneficial to overcome this limit. Also would be nice to set different resulting mesh density settings for each metaball. Currently the setting works for all metabals which are in a same set. That means if one sets certain value of mesh density average distances from vertexes in all resulting mesh will be almost same. In some case we don’t need high detail inside of tree, or some areas which are plain and do not have much variance in surface.
This is not currently available feature of metabals and would require further investigation, probably new metaball creation algorithms too.
The “work around” in case of making additional polygons in flat areas, which are not needed would be after creation of surface, to apply a mesh optimization algorithm, which would try to reduce polygons where they are not needed. The bad thing about this “work around” is we spend double time generating unnecessary polygons and then trying to remove them. Also in some cases it is good to have high detailed mesh even in flat areas if we are considering to apply displacement maps at the render time or before.
The corners of holes in a tree would look very good if used metaballs technique, it would create an inner surface for a tree, and the corners of the holes would look rounded, not sharp, which is how the natural tree holes look like
common disadvantages of current metaballs algorithms is creation of so called bad mesh topology. Also if there is a polygon in a mesh, which vertex distances are much bigger then the average of the models vertex distances, the resulting surface after applying metaball operation would result a hole in a mesh at the given polygon.