Kineme 3D

You can have multiple objects within one FBX file. The 3D object loader patch has a "objects " output pin that will give you a structure of objects. Use traditionnal structure index member patch to access any of these object separately.

You would then need one RENDERER per object. This will allow you to have one TEXTURE per object. If you need fancy shaders, then each renderer will have to be placed inside a GLSL patch.

hope this helps.

(franz was completely correct, I'm just fleshing out some more detail)

to render all objects in a multi-mesh file, you'll want to iterate over the output Objects output (it's a structure of kineme3D objects for each mesh it finds in the file). Caveats: If you enable Center or Normalized, each mesh will get scaled/translated (rather than collectively) individually, which will likely make them useless for this type of usage.

To use multiple materials, you'll need a GLSL shader -- Kineme3D only imports 1 layer of UV data, and doesn't import any color data. It doesn't try to import textures for you because there are too many quirks with trying to divine what each file format means when it references textures (some don't provide any path information at all, some do absolute paths, some do relative paths, some reference other files that in turn reference textures, etc...). It's a pain, I know, but it was the best I could do, given the archaic setup it's in (lots of different formats, each created at different times for different purposes).

If you're hoping QC to become the next Maya, you might want to reconsider... there are a lot of things missing from kineme3d that are in the most basic 3d modeling packages. You're best off using those tools instead to bake textures into a simplified final, and use the simplified one in QC.

Don't know what datas are outputed from the object loader but there is certainly a vertex structure somewhere.... As it can be normalized to 0 to 1 what will happen with a patch that convert the structure to RGB values ( "3D structure to RGB patch) : Then we can pass it in every core image patch to treat it and reconvert the result (with a "RGB to 3D structure patch") the result should be totaly imprevisible but undoubtly awesome....;) Theorically possible ?

In theory, this is possible.

In practice, I don't see this going anywhere. Vertex data is actually 2 arrays -- one for vertices, and one for indexes into the vertex array (so a cube only stores 8 vertices, instead of 36 (one for each corner of each triangle)). Messing with indexes is going to crash, while modifying vertices would be fine. (that's what you were discussing anyway, no problem there).

A|x has done some research into Geometry As Images, but I've not had much success with it personally.

There will be a much better solution to this in SnowLeopard, so I'm not going to touch it until then.

Interesting. In a more generally discussion : Do you mean there is no way to detach the triangles ? Because some of verticles are used to construct multiples polys... So the volume can't be opened ? Is there a way to convert (for exemple this cube with 8 verticles) to a sets of 12 separated triangles with 36 verticles ?

Basically, what cwright said, but I'll add that there's a big difference in structure between the average object and an image.

The image is a big 2d grid, so each pixel connects to 4 other pixels, except at the edges where there is a break in the surface. An object on the other hand is normally a solid object, with no breaks in the mesh, and a vertex can connect to any number of other vertices.. so I've no idea how you would go about converting an object to a texture without totally changing it (and if you changed it, the texture wouldn't represent the object as such, so if you applied a filter and converted back the result would be very random...)

On the other hand, it's perfectly reasonable to work the other way, and convert an image into a mesh. With some careful planning of the texture, you can make pretty much any shape from the texture too. This is actually part of how my 3d paint tool works.. a texture is generated for a base shape (grid, sphere, cube or whatever), and you can then manipulate it in various ways.

And yeah, filters work fine so long as you're careful to handle it the right way, and there's a ton of fun stuff you can do with it. E.g it's possible to make a sphere, apply a landscape to it to make a 3d world with mountains, add animated 3d water in the valleys, and then blur it slowly.. the blur is applied both to the 3d mesh and the surface texture. I did a quick test of 3d blur ages back with an early version, you can get an idea of what it's like from this bad quality animgif : http://img208.imageshack.us/img208/7772/meshbluraj2.gif

Hmm.. I've improved it by 100x or so since then, but I've been focusing on the 2d site lately and the 3d part is currently broken.. i should fix that and do some videos.

It depends on the mesh - by default, Kineme3D just loads the vertices and indexes as they're defined in the file -- if they're all separate triangles then it uses that, if they're shared, it uses that. It doesn't care one way or the other, and doesn't make any changes, except if you simplify -- that attempts to find shared vertexes, and merges them together. (The alphas used a slow algorithm for this, the release candidates and public release adopted a faster algorithm for this -- they both miss some though, because they're a few tiny units apart, so it thinks they're different).

It's trivial to separate them (though it uses more memory, and renders a bit more slowly) -- actually, this separation is necessary for an explosion patch, so it's on the todo list.

The vertices on a cube connect to 3 other vertices.. how do you get that to fit into a texture, where each pixel connects to 4 others?

You could unwrap it (imagine the box is made from paper, like origami.. you unfold it to make it flat). But then the shape is lost, so your filters won't have any real meaning..

So it is how the "simplify option" works : exemple you load the "famous like cube"with 36 verticles and it simplify it to a more light 8 verticles object.

Explosion ;) This was exactly my thinking.... And more generally deformations with GLSL... (It's already possible but you have to prepare two models in a 3D package (one normal and the other explosed) then blend them with the 3D blend patch...)

Another problem is lack of vertices.. and adding new ones.

Say the cube example. You have 8 vertices.. convert it to pixels, and you have 8 pixels. A 2x4 image. Not much fun.. Even with a more practical example, with say 14,955 vertices: it's an odd number, you must either have a 14,955 x 1 image (no fun) or you must have some 'empty' pixels which don't contain a point. If you apply a filter, those empty pixels might get filled, so you're added geometry..

I guess there's a way to do it though. It's the reverse of how I work in my paint tool (maybe I'll use this for an object loader :)

You make a 256 x 256 texture say. Then you select a point in the centre of the object, and trace 256*256 points outwards in different directions, calculate the intersection with the surface of the object. You then have a point that you can store in your texture, and if you're sampling these points in an ordered way, the object can be reconstructed from the texture. Effects would work correctly on this texture too.

There are problems though: it would only sample one point as it travelled out, so if there was more geometry beyond the first surface it hits, you would lose that geometry. It would work with a cube or a sphere, but not a teapot: you would lose the handle.

I understand, so it just can works with pre-detached triangles.... Some 3D package do that when you start from a primitive and convert it to an editable mesh. But to be possible it must know which verticles form a triangle... ( are connected...i suppose ?) Are those informations provided with the mesh in the 3D loader ?

thanks psonice for posting your thoughts on this (they mirror my own, more or less -- there are some fancy algorithms to deal with some of the nastier problems, but overall it's a pretty high-caliber feature that isn't likely to happen anytime soon).

I'm glad it wasn't me that brought up the nastiness -- I'm starting to sound like POL lately, with all my "this feature isn't possible" rants...

Each triangle is just 3 indexes -- indexes into the vertex array. Simplification tries to find duplicate indexes (i.e. the vertex at index 42 is the same as the vertex at index 84 -- throw out one of them, and change all the indexes that point to 84 to now point to 42).

Connectivity between triangles (i.e. triangle 7 is touching triangle 13) can be found if two of their edges are shared (normally, you just check to see if two triangles have two common indexes -- this doesn't work if there are duplicates, which is why simplification is handy.)

There IS going to be an explosion patch... that's cool!

That's just the way it goes really.. when you're just using this stuff, you see something and thing "hey, it'd be great if i could do this, but it's not possible", so you fire off a feature request.

If you're writing it though, you tend to look at it and think "hey, lets add this feature". Then you consider the amount of work involved.. and decide maybe you don't need it all that badly after all ;)

If only there was a good way of getting the end users to consider that last bit eh?

I think what you needs to be the overwhelmingly understood by anyone that is using the Kineme 3D, or QC in general, is that it is really a "presentation" format at it's heart. You supply it with what you want, and it gives you tools to present and interact with it. (just my opinion!)

For instance, I may use a video as a source with QC, but I don't expect QC to become a video editing suite because I can use video, or a multi-track recorder just because I can use audio.... just like anyone who expects it to become Maya or Blender because of a 3D plugin is going to be disappointed. :o(

All the same, I am finding a nice working method using a handful of other programs for prep, and then putting the finished stuff into QC.

Ok THX for the lights. Last questions... So edges are not provided as data (ex: this 2 verticles are this edge) And there is nothing that says "this 3 edges are this triangle"

For a second I thought you were reference Pol Pot, not Pierre :o)

i'am in agreement with you Georges, but kineme 3D is far to be just an object loader...and try to break the barrier between pixels and polys is fun ;)

Oh no, don't take me the wrong way. I'm all for pushing the limits... I think that asking for the moon is the way to at least get half way there :o) It seems like Chris had a little twinge of beating himself up there though! I envision him sitting there answering email after email...

I think the idea is really cool.

right now i'm emulating an explosion with the morpher patch..... very tedious (read: hand made) ... so +1 for an explosion modifier (already requested, i guess....)

EDIT: (note to dev) finally, one more use for the morpher.. ;)

I'm not sure exactly what you're trying to accomplish...

No edge data is provided -- it's implied (each face defines 3 edges by virtue of existing). There's not an edge list, if that's what you're interested in. There's not much of a point to such a data structure in Kineme3D (though edge lists do serve handy purposes, and may exist in the future, just as the smooth normal cache exists now -- to speed up a specific operation).

What were you planning on doing with edges/edge data?

Yup, me too :o) Actually, the morpher is kind of cool to use in wrong ways.

Hey Guys,

thank you very much for the great explanations here. I was able now to figure out some aspects you all explained. Thanks also for the autors of the 3-d menue system and especialy for the author of the "prism" QC example... (that was great for understanding the iterator functions...). I will upload a small QC composition with an architectural model from archibase. Maybe that is helpfull for some other newbies like me? At least the iterator part :-)

I have played around also a bit with the "image-path" aspects. I am not right sure if that leads somewhere, but i made a little experiment inside the QC-file using a directory scanner patch... It is not working as expected by me (probably i am doing something wrong), but maybe somebody more experienced could say someting to...

As a last note: i would not try to use QC to make a homebrew Maya :-) But i think that QC has (could have) some real strenghts for presenting 3-d stuff. At least, as i allready said that: i am trying to make some nice Multi-Touch thingies wie QC. For me as a non-programmer is extremly exiting to be able doing so great stuff with so little knowledge ;-)

Cheers,

Sandor Rozsa

corporate design cologne http://www.cd-cologne.de http://www.xtuio.com

Glad you enjoyed the "prism" example, but for posterity's sake and all, the loading with iterator part is all Chris :o)

Actually, I didn't realize that had become the prime "multi-object" example until this moment... Sorry for posting it in that case, I probably caused undo hassles!

Stick to "single object type" 3D files for 100% Kineme approved I think, as there was no multi-object example in the official examples :o)

I shy away from multi-object files because of the performance hit that iterators in general have in QC. But Im not convinced that your statement about multi-object files somehow not being kineme approved is right I dont read anything into the lack of a multi-object example. And if I wanted to do something specific, I dont absolutely have to use an iterator.

multi-object files aren't a problem (they leaked memory in Kineme3D 1.0 due to a silly bug on our part, but otherwise have no problems). The Knight vs Goblin demo composition uses multi-object files.

There are some quirks (center/normalize will treat each piece individually, rather than collectively) that users should keep in mind, but otherwise I don't think anything bad will happen from using them.