nemyax

aen916 You should turn the tris into quads in your model before getting it into A:M. Import your STL into an external package, run a tris-to-quads op and export to OBJ. You can do the whole thing in Blender (which anyone doing any kind of 3D work ought to have handy anyway just in case).

"BAD" replaced by "GOOD"?

The choice of colour for the clouds maybe?

Weird perspective on the hangar?

John Bigboote Wouldn't the autoscaling affect the weighted CPs? The results could be ugly at the joints.

HModel::BuildExportModel and HModelCache::BuildExportModel are probably buggy.

TopsyTriceratops My Blender plug imports geometry, UVs and bones from MDL. After import into Blender, you can export everything to FBX, which is very popular. OBJ doesn't support bones, and X is near useless.

I might take a stab at LSCM unwrapping after I've tackled it in my own project, but I'm not promising anything.

I suppose you realise that the tessellation control and tessellation evaluation stages are performed at every frame, unless you employ some post-transform cache trickery. You might be better off precalculating your tessellated surface in the main program. I don't think A:M users really care. For example, when I released the Blender-to-MDL addon, a couple of wows were voiced, and then everyone promptly forgot all about it.

There are no "splines" or "polygons" at the renderer level really, just sets of point-based input data for the shading algorithms.

LSCM unwrapping should be doable with the current SDK. I don't think it has to depend on the core application. But things like painting in 3D do need some serious core support.

HAMR probably uses the pre-shader era fixed functionality pipeline.

It isn't supported in the sense that the animation engine hasn't been ported over from the 2.7* branch yet. The renderer itself doesn't care what exactly happened to the polygons that are being thrown at it.

robcat2075 Those are reference boards, and vendors don't have to stick to exactly the same specs.

Not necessarily. It's faster that way but it isn't a hard requirement with modern shading languages.

pixelplucker It looks like what you want is for A:M to go on Steam.

That would simply mean animating at 6 FPS, right?

This boils down to deciding where you should composite and where you should re-render. But that's your own call anyway, not the renderer's.

Prior art: A:M's "ticks".

Spline patches are a very finicky geometry type, and it's hard to program these kinds of features into them. It goes a lot easier with polygons.

Happens all the time in computer graphics.

You and your turned-on belles.

It has nothing to do with subdivision. All I'm doing is looking at the valency of vertices. If there are four edges at a vertex, it's an intersection of two splines (the adjacent faces tell us how exactly the splines cross). If there are 3, 5 or more, it's a terminal point for multiple splines. If there are two, it's just a CP in a spline. Patches are created from existing faces that are valid for that purpose. In a good subdiv model, they'll all be quads and therefore valid.

Rodney The solution can be derived from the examples that rodger_r posted: Run a closed loop around the patches that contain the "pole" CP. Delete everything inside that loop and build a grid-like pattern with a similar shape. There's an extra spline that doesn't have a match. Hook it.

Thanks for the replies, folks. Very interesting. What really matters to me here is how many splines (except the case of 4) converge at the central point—what they call poles in subdiv modelling. I only showed five- and three-edge poles. Such poles are common in subdiv models, and it's a best practice not to let your pole have more than five edges if anyone can see it. So that's what you get when you bring subdiv models (good ones, mind you) into A:M: poles with valency 3 and 5 all over the place. Because A:M treats these spots so differently, it would be nice to have a way to respline them that everyone's happy with.