Indigo 1.1.1

Post by **fused** » Fri May 30, 2008 5:14 am

OnoSendai wrote:UV coordinates may be a different issue. I guess the question is, will you ever need to have two different uv coordinates at the same vertex position, for different triangles, on a C1 continuous surface?

of course!

Whaat · Post by **Whaat** » Fri May 30, 2008 5:22 am

fused wrote:
OnoSendai wrote:UV coordinates may be a different issue. I guess the question is, will you ever need to have two different uv coordinates at the same vertex position, for different triangles, on a C1 continuous surface?
of course!

+1. This is bound to happen often, especially in SketchUp.

Post by **OnoSendai** » Fri May 30, 2008 9:27 am

Testing 'water level' code.

The current code just discards triangles if all vertices are beneath the the given level of displacement.

Kram1032 · Post by **Kram1032** » Fri May 30, 2008 9:30 am

Much more water level like than it should be xD
Looks pretty interesting

F.ip2 · Post by **F.ip2** » Fri May 30, 2008 9:34 am

Ono

very interesting addition - how is the speed handling for displacements?
Does it affect render time badly or not so much?

Post by **OnoSendai** » Fri May 30, 2008 9:39 am

Hi F.ip2,
It's hard to say how it affects speed.
The subdivided tris are inserted in the kd-tree like the usual tris, and the kd-tree is pretty fast.
Plus subdivided tris are usually nicely distributed, and nice and small which lends itself to fast kd-trees.

In summary, you'll just have to do a few experiments and see if the speed is acceptable for you

suvakas · Post by **suvakas** » Fri May 30, 2008 5:57 pm

Hey Ono,
What are your plans about this dupli verts issue?
Is there any solution you could use or..?

BbB · Post by **BbB** » Fri May 30, 2008 6:42 pm

Thanks for this addition Ono. Looking very good.

CTZn · Post by **CTZn** » Sat May 31, 2008 1:22 am

Hi Suv, CTZn and other exporter writers

Oh man don't call me exporter writer, I can't assume that ! In the best case I'm a dabbler

Well I have to refresh my knowledge on continuity as I forgot even the basis. Invitation acknowledged.

Whaat · Post by **Whaat** » Sat May 31, 2008 6:19 am

suvakas wrote:Hey Ono,
What are your plans about this dupli verts issue?
Is there any solution you could use or..?

Yeah..we need an answer on this. This has major implications for the exporters. The new features of 1.1.1 are basically unusable in SkIndigo because of this issue.

It could be weeks before a new SkIndigo is released if I have to rewrite the mesh exporting code.

Post by **OnoSendai** » Sat May 31, 2008 1:14 pm

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

Code: Select all

<mesh>
		<name>mesh2</name>

		<normal_smoothing>true</normal_smoothing>

		<merge_vertices_with_same_pos_and_normal>true</merge_vertices_with_same_pos_and_normal>

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

			<vertex pos="-1.5 0 0" normal="0 -1 0" />
			<vertex pos="-1.5 0 2" normal="0 -1 0" />
			<vertex pos="1.5 0 2" normal="0 -1 0" />
			<vertex pos="1.5 0 0" normal="0 -10 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>

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

The changes here are that the uv coordinates are separated from the vertex normals and positions.
Triangles have indices into the vertex pos and normal array, and also into the uv array.

The

Code: Select all

merge_vertices_with_same_pos_and_normal>true</merge_vertices_with_same_pos_and_normal>

line tells Indigo to merge all vertices sharing the same position and normal (uv coordinates will be unaffected tho).

Thoughts?

CTZn · Post by **CTZn** » Sat May 31, 2008 1:20 pm

Makes sense to me if I'm not wrong:

You are separating parameters that should be separated but were not until now, sounds fine. Optionally one can merge that all again. How far from truth ?

I suggest you use the full world "position" in the tag name

Post by **OnoSendai** » Sat May 31, 2008 1:29 pm

Yes, that's more or less correct CTZn.

The reason i'm using short names here (v, pos etc..), is that when you have large meshes in an .igs file, the amount of characters in the element/attribute names makes a significant difference to file size.
Actually, I think I'll convert more of the names to 1 char names

Code: Select all

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

<t v="0 2 1" uv="0 2 1" />

Post by **OnoSendai** » Sat May 31, 2008 1:31 pm

Also, note that this new format will be inside an '<embedded_2>' element, as opposed to <embedded>, to maintain backwards compatibility.

Whaat · Post by **Whaat** » Sat May 31, 2008 2:02 pm

I can't quite wrap my brain around this at the moment, but from the sounds of it, this would solve the problem of meshes with duplicated vertices not being subdivided properly.

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

Indigo 1.1.1

Who is online