Indigo 1.1.1

[CTZn]

I am still fuzzy on what happens to two vertices with the same position and normal but with different UV coordinates.

They use very probably a different value for displacement = ripped apart in the direction of the normal.

Sounds the reverse of what we want, huh ?

Maybe merging UVs would make more sense (or that's what you are talking about) ? I'm still not sure

[Whaat]

I've been testing out the new procedural fractal stuff. This is the usual type of output that I get. It seems like there is a bug with the procedural code related to the uv coordinates.

In the one image, FBM is applied to the diffuse texture.
In the other image, a diffuse texture is applied to the same geometry using the same uv coordinates.

[Whaat]

Another issue that I don't think has been mentioned:

normal smoothing doesn't seem to work at all. I assume it has been disabled. Is this permanent?

[suvakas]

Hi,
I'm thinking of a new mesh description format like this...

What about 3ds and obj formats? xml embedded meshes are rarely used in Max these days. They are slow (because maxsccript is not C) and the poly count is also limited.

[edit]
@Whaat
The smoothing issue is know and (i may be wrong) occures on those "bad meshes" that have dupli verts?

[fused]

ya, what about obj format? i always tried to keep away from it, becaues of the size of the files when having really large meshs. (obj tends to be smaller, especially obtimized obj)

[dougal2]

MtI Exports to OBJ, it's about the only option at present. The only drawbacks that I experience are I think to do with bugs in the Maya OBJExporter plugin
Also, I'm not sure if OBJ supports multiple UV sets.

[CTZn]

It does. You just have to be aware that all indexes start at 1, not 0. I couldn't find the mention of a limit for material definitions, vertex textures (uv maps) or anything else, from various sources.

Download here the most complete I found (link to download page, zipped pdf). Here a simpler one (txt, less data).

Amongst other unused features, the obj format can hold:

Free-form curve/surface attributes

Five types of free-form geometry are available in the .obj file
format:

o Bezier
o basis matrix
o B-spline
o Cardinal
o Taylor

These being rational or not.

I love the obj format

[OnoSendai]

I don't think OBJ supports multiple uv sets.

[CTZn]

Mmh that's right, I tried with Maya. That's why they don't mention a limit.

*argh*

[OnoSendai]

ya, what about obj format? i always tried to keep away from it, becaues of the size of the files when having really large meshs. (obj tends to be smaller, especially obtimized obj)

What about .obj format?

[OnoSendai]

Actually.. I might drop normals altogether from the embedded mesh (embedded_2) definition, and just compute the shading normals in Indigo.

[CTZn]

ya, what about obj format? i always tried to keep away from it, becaues of the size of the files when having really large meshs. (obj tends to be smaller, especially obtimized obj)

What about .obj format?

Is that irony, Ono, when you just atomized a pure child's (me) dream ? Well obj can refere to multiple materials, maybe one ould hack that by evaluating one material (eg including texture)

Code: Select all

    g front
    usemtl red
    f 1 2 3 4

when a grouping (g) statement occurs. Because i believe it's ok to redefine already defined faces, I mean appending

Code: Select all

    g front
    usemtl blue
    f 1 2 3 4

after the previous code should be ok. Dunno if that hack can really be implemented, but if yes then you can set as many textures than materials to a single face (within the same uv space off course).

I hope that makes sense at least...

It seems like there is a bug with the procedural code related to the uv coordinates.

That could be right, but are you sure the UVs are between 0 and 1 ? They can be higher in many cases, and maybe Indigo can't manage procs above the 1 coord ?

[fused]

ya, what about obj format? i always tried to keep away from it, becaues of the size of the files when having really large meshs. (obj tends to be smaller, especially obtimized obj)

What about .obj format?

spotted an error:

"i always tried to keep away from it". i dont mean obj format, i tried to keep away from embedded.

but still, i dont really know what you want

[OnoSendai]

Ok...
here's what I'm thinking for the new embedded mesh format.

Code: Select all

<mesh>
		<name>mesh2</name>

		<normal_smoothing>true</normal_smoothing>

		<embedded_2>
			<expose_uv_set>
				<index>0</index>
				<name>albedo</name>
			</expose_uv_set>

			<v p="-1.5 0 0" />
			<v p="-1.5 0 2" />
			<v p="1.5 0 2" />
			<v p="1.5 0 0" />

			<v p="-1.5 0 0" />

			<uvs uv0="0 0" uv1="0 0" />
			<uvs uv0="0 1" uv1="0 100" />
			<uvs uv0="1 0" uv1="100 0" />
			<uvs uv0="1 1" uv1="100 100" />

			<triangle_set>
				<material_name>mat1</material_name>

				<t v="0 2 1" uv="0 2 1" />
				<t v="4 3 2" uv="0 3 2" />
			</triangle_set>
		</embedded_2>
	</mesh>

Shading normals will be computed internally by Indigo.

Spatially adjacent triangles should index the same two vertices for the shared edge, if and only if the surface is supposed to be C1 continuous over the edge. If there is supposed to be a crease, then the edge vertices should be duplicated, and each triangle should index different vertices.

Makes sense? Thoughts?
Exporter writers: do you think you can export your meshes in such a format?

[filippo]

wonderfull new features....
filippo