How to refresh clips?

[Styler]

Hi guys,

 

I'm doing import a new model with updated textures into HA and it doesn't reload them until I do any operation relative to textures (open for view, hitting 'render' and etc.). How to update them via SDK?

[Fuchur]

Good question, next question?

I wondered about that too... it is even hard to do it in A:M... I open the image in A:M and close the window again.

That does the trick... maybe you could open and close a image-view too?

 

But I am sure there is a better way to do that...

See you

*Fuchur*

[robcat2075]

Since rendering will force an update, how about if you forced a one pixel render?

[Styler]

I just removed all old clips first. seems like works now.

[robcat2075]

I like how you solve your problem after you ask the question.

 

It should always be that simple!

[Styler]

Nothing is really simple in H:A world without proper docs. But I have some results

http://youtu.be/gdphjxRRCeU

[NancyGormezano]

nice! AND EXCITING!

[robcat2075]

that looks promising! I notice that at the end Thom has some bad patches. Is that something you hope to fix?

[Rodney]

Very nice.

[Styler]

I notice that at the end Thom has some bad patches. Is that something you hope to fix?

There's no an easy answer for this. As you know A:M has specific things such as 5 point patches (5pp) and 4pp with hooks. After polygonization everything goes to 3-4 poly faces. I managed to turn them into 3-4-5 poly faces, so they look exactly like in A:M.. But, on the way back to nurbs you have to know which 5 polyface is it: 4pp+hook or 5pp (and of cause we lose all in/out tangents). WIthout extra information it can't be done properly, 'cause the way how A:M builds patches is very sensitive to their ordering. I tried different approaches and couldn't find robust solution. In plugin I use generic way nurbs->poly->nurbs with using helper functions provided in SDK + some fixes, which is not the best way. That's why we have all these crazy stuff if some of 4pp+hooks or 5pp has been found in model. I think, that more accurate result we might reach with using only 4pp.

[robcat2075]

 

I notice that at the end Thom has some bad patches. Is that something you hope to fix?

... But, on the way back to nurbs you have to know which 5 polyface is it: 4pp+hook or 5pp (and of cause we lose all in/out tangents)....

 

How about if the bitmaps created in 3D coat were applied back onto the original model in A:M rather than importing the painted polygon model?

 

 

5-point patches and hooks are part of what makes A:M great to model with and make simple topologies for complex objects possible. A painting solution that can't properly preserve them will be of limited use.

[Styler]

Can you make single unwraped UVSet in A:M? It's kind of possible only in this case. (hmm, actually the great idea for next plugin =))

Note from moderator Robcat2075: Styler, Sorry! i accidentally ruined your post while trying to reply to it. see below.

 

If you can recall it and want to re-post it that is fine.

[robcat2075]

Styler... I accidentally destroyed your previous post while trying to reply (I unintentionally hit "edit" rather than "reply") but here is the jist of it...

 

 

Can you make single unwraped UVSet in A:M? It's kind of possible only in this case. (hmm, actually the great idea for next plugin =))

A:M can automatically create a single map now, but it is a set of discrete non-contiguous tiles on one map, which is a problem for post-processing any painting you do in another paint app.

You can pre-wrap a model manually with a few cylindrical decal applications and get an all-on-one map that works well in our current 3DPaint app.

 

Here is how Thom would be done. (post #10)

[Styler]

Where can I see 3DPaint in action?

[robcat2075]

You can see my video demo of it in this post

[robcat2075]

Styler... if the problem is that a polygon model created from a spline model doesn't remember which patches were 5-pointers and which patches were 4-pointers with an extra hook, how about writing an extra data file on export that lists each patch and explains what kind it was and then use that when the polygon model is is being imported back to make the patches right?

[Styler]

yes, this is a part of the problem. not only with patches, there are some others: ordering of polygons, control points, mapping and etc. i can save all necessary extra data, but it will be lost on the way back. painting app should return everything in the same order, otherwise saved data will be not valid.

[robcat2075]

So build a table that translates the old order to the new order?

[Styler]

relying on what? control points positions? i think too much of conventions. it must be simple and robust solution

[robcat2075]

When you say "order" are you talking about the actual order of item in the file?

[Styler]

in file data arrays, yes. if another app that does import geometry will slightly change ordering of polygons on the way back...

[Fuchur]

I am not sure but since the format of a:m is xml based could you save customized xml nodes to the file at some point where A:M will not get confused to solve this problem? since older versions of A:M can load projects created with newer versions (and additional nodes and properties which had not been there before it should be okay with that). would that help?

[robcat2075]

in file data arrays, yes. if another app that does import geometry will slightly change ordering of polygons on the way back...

 

So... the problem is that even though the physical arrangement of vertices and polygons in a polygon model coming OUT of a 3D paint app is the same as the polygon model that A:M sent IN, they are not necessarily listed in the same order, making it hard to know the correspondence between the input surface parts and the output surface parts.

 

Do I have that much right?

[Styler]

yes, it's correct