(Maybe if we thought of a potential technique for doing this as adding- and subtracting FACES rather than vertices in the Morph steps, then maybe that seems a little bit more viable? Maybe then it would almost be just like the Build Modifier, in some ways.)
Iām using 32 bit windows XP too. The only thing i could think of was that the script was saved here on F drive. I made it internal and resaved with packed dataā¦ otherwise NFI.
Attachments
SCANNER.blend (1.48 MB)
Okay, itās working now. Iāll see if I can figure it out!
Notice that when morphing, GIMP forces both the source and the target images to have exactly the same number of control points? Same thing as Blender, and for the same reason.
Adding and deleting vertices arbitrarily seems to be a big technical solution to a problem that could easily be solved simply by adjusting your technique, with better results.
Also, Iām intrigued by what you mean by āmorphing materialsā. How is this different from cross fading in post?
Yeah, but the two images donāt have to have the exact same number of pixels, and thatās the more direct analogy: pixels to verts. So if a Morphing system would utilize a version of control points, thatās cool. In fact, I think that itās probably mandatory and efficient.
I donāt mean anything different than cross-fading. But Iām saying that if you have two complex models where the Materials are scattered in different places (again, consider two cars) then it becomes impractical to keyframe all of them and to align all of them.
No it isnāt. In this case, vertices are directly analogous to control points, not pixels.
Pixels and verts are very different concepts. Not analogous at all, especially when it comes to morphing.
(BTW, I think they actually do have the same number of pixels.)
Exactly my point; donāt animate materials at all. Do it in post as a cross fade.
Where did you come up with that? Who ever said anything about not using control points or using the vertices as the control points? That makes no sense at all because Iāve been explicitly talking about morphing objects with different numbers of vertices.
Uh, okay.
jumping in late here ā but the original Youtube video that is the source of this whole discussion ā how is it different than Blenrig?
daren,
Blenrig looks very cool, but itās not necessarily what weāre talking about - at least what I was hoping to find. Weāre basically talking about taking two disparate Objects and creating a morph between them. But it turns out that, apparently, all existing techniques (like the one in the video I first linked to and the ones you linked to using Blenrig) all have the same number of vertices and they donāt morph the Materials. So their functionality is much more limited in scope than I was hoping.
I was dispelling the myth that pixels and verts were analogous.
There is no analogy between pixels and verts. Completely different beasts with almost nothing in common.
Control points, on the other hand, are analogous to verts, and that is why the source and the target have the same number.
Iām sorry, but I donāt understand the point that youāre trying to make.
If youāre saying that, in our hypothetical morphing add-on for Blender, that we would need to have reference handles for each of the two targets, and that there would have to be the same number of those reference handles for each target (as is done with 2D morphing) then I agree.
If youāre saying that you, like, use the Objectās own vertices - in and of themselves - as the reference handles and, therefore, there would have to be an identical number of vertices in the original Object and the Object it morphs into, then I disagree. I only disagree because thatās redundant and what the technique described about five minutes into here already does.
That, indeed, is the point I and others before me have been trying to make; you can do it all with existing tools, and achieve better results.
I would also add that in a production, many of the examples youāve cited so far would be better dealt with as a 2d morph, combined with other tricks, in a compositor.
Okay, so if youāre saying that itās impossible or not worthwhile to morph Objects of different numbers of vertices, then you shouldāve saved us both the time and just said this from the start or, better still, not even bothered writing in a thread dedicated to that idea.
The existing techniques that have been promoted simply cannot achieve what I have explicitly said that Iāve been trying to achieve from the very start. Saying, āCreate all new models with totally different topographies and then use Nodes to morph between dozens of hundreds of different Materialsā is not a solution. If it were, then weād see such effects all the time.
BatFINGER,
Iām kind of struggling with this (event though you noted that you didnāt fully develop it).
Itās VERY cool, as far as I can tell, but I canāt get consistent results from it. Also, as it relates to the idea of morphing, it doesnāt seem to result in a scanned Object which is the same number of vertices as the Scanner or whatever.
So, for instance, I have a simple, 498-vertice Batman head here. I scanned it, and the resulting head was 3038 vertices (and they were, ya know, kind of haphazard and messy). There is also this odd cube-like attachment to the mesh:
But the idea is very cool. When I make the āScannerā itself visibleā¦that is very cool!
I donāt know whether you were just thinking of this as the start of a larger project. If so, I think itās cool and worth finishing, in my opinion. If youāre saying that itās fully functional right now, I couldnāt personally figure it out. (But, obviously, Iām pretty much a novice here.)
I said use a compositor, not nodes.
You can achieve what youāre after with existing tools, using methods explained to you already.
You do see these effects all the time.
Gah! Forget it. Youāre right; I shouldāve stayed out of this thread.
Yeah, yeah, yeah. āThe solution exists, I just canāt demonstrate it or point to any existing examples. Just trust me!ā
Right.
The āsolutionā offered is to build totally new models with identical number of vertices from scratch. This is not a solution. Thatās a ridiculous waste of time and, of course, nobody ever does it. Otherwise, youād see morphing done all the time but, as shown by your lack of references to morphs of different Objects, it isnāt.
Once again, the objective would be to be able to take two separate Objects - letās say two car models created by two different people - and to be able to morph them. No, saying, āJust build two totally new cars and use ShapeKeys!ā is not a viable option.
Even though itās claimed that BlenderStorm is actually just some sadistic joke that some developers like to play on people to waste their time, here again is the most I made at that site:
Man, this is an exercise in futility.
Itās painfully clear that the problem lies squarely between the keyboard and the chair.
David Brennan you just donāt seem to understand what what several people in this thread already suggested. It is NOT a ridiculous waste of time but in fact very simple. Iāve just tried to morph suzanne into a cube, which both have completely different polycounts and it works like a charm and only took me about 1 minute.
And about the materials. You donāt have to morph thousands of materials. Just morph Object A with the set of Materials Ma into the shape of Object B and at the same time morph object B with the set of Materials Mb into the shape of Object A. Then render both morphing animations separately and fade between them in compositing. That should exactly give the effect youāre after.
All in all the amount of time this takes (excluding the rendering time) should range around 5 minutes. So Iāve realy no clue why youād want to code a specific tool for this purpose ?!
didnāt see the above post^^
Thatās fantastic! Please explain the steps.
These are the two models that I first thought to morph, so if you could just do it with them as a demonstration, thatād be great.