I have a really frustrating issue. I have a tool that emits mesh2
objects with embedded texture indices.

vertex_vectors {
	4,
	<...>
	...
}
face_indices {
	4,	
	<...>, 0, 1, 2
	...
}

This is then being loaded by a Povray file:

object {
	mesh2 {
		#include "thing.inc"
	}
	translate <...>
}

I want the texture list to be in the Povray file, not in the machine
generated include file, because it's source code. But the syntax appears
to be insisting that the texture_list clause goes *between* the
vertex_vectors and face_indices clause. In order to emit it there, my
tool needs to know stuff about the structure of the Povray file that it
really shouldn't know.

I've tried defining the texture list with #declare, but that doesn't
work because texture_list isn't an rvalue and can't be assigned to a
variable.

Is there any wrinkle of syntax that will allow me to get the texture
list out of the include file?

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│ "There does not now, nor will there ever, exist a programming
│ language in which it is the least bit hard to write bad programs." ---
│ Flon's Axiom

Post a reply to this message

Am 07.12.2013 14:26, schrieb David Given:

> I want the texture list to be in the Povray file, not in the machine
> generated include file, because it's source code. But the syntax appears
> to be insisting that the texture_list clause goes *between* the
> vertex_vectors and face_indices clause. In order to emit it there, my
> tool needs to know stuff about the structure of the Povray file that it
> really shouldn't know.
>
> I've tried defining the texture list with #declare, but that doesn't
> work because texture_list isn't an rvalue and can't be assigned to a
> variable.
>
> Is there any wrinkle of syntax that will allow me to get the texture
> list out of the include file?

There is indeed: While the documentation claims that the texture_list 
must go between vertex_vectors and face_indices, the actual 
implementation also allows it to be placed /before/ vertex_vectors.

Post a reply to this message

On 12/07/2013 08:52 AM, clipka wrote:
> Am 07.12.2013 14:26, schrieb David Given:
>
>> I want the texture list to be in the Povray file, not in the machine
>> generated include file, because it's source code. But the syntax appears
>> to be insisting that the texture_list clause goes *between* the
>> vertex_vectors and face_indices clause. In order to emit it there, my
>> tool needs to know stuff about the structure of the Povray file that it
>> really shouldn't know.
>>
>> I've tried defining the texture list with #declare, but that doesn't
>> work because texture_list isn't an rvalue and can't be assigned to a
>> variable.
>>
>> Is there any wrinkle of syntax that will allow me to get the texture
>> list out of the include file?
>
> There is indeed: While the documentation claims that the texture_list
> must go between vertex_vectors and face_indices, the actual
> implementation also allows it to be placed /before/ vertex_vectors.
>

better? ... http://wiki.povray.org/content/Reference:Mesh2

Post a reply to this message

[...]
On 07/12/13 13:52, clipka wrote:
> There is indeed: While the documentation claims that the texture_list
> must go between vertex_vectors and face_indices, the actual
> implementation also allows it to be placed /before/ vertex_vectors.

Not quite --- it needs this patch:

diff --git a/source/backend/parser/parse.cpp
b/source/backend/parser/parse.cpp
index 7268519..5671853 100644
--- a/source/backend/parser/parse.cpp
+++ b/source/backend/parser/parse.cpp
@@ -4123,7 +4123,6 @@ ObjectPtr Parser::Parse_Mesh2()
                        }

                        Parse_End();
-                       EXIT
                END_CASE

                OTHERWISE

Here is a non-working example which this patch makes work:

mesh2
{
	texture_list
	{
		2,
		texture { pigment { rgb <1, 0, 0> } }
		texture { pigment { rgb <0, 1, 0> } }
	}

	vertex_vectors {
		8,
		<-2719.2913915965546039, -893.33239410140299697, -767.54170874189844653>,
		<-2718.0920180748885286, -892.13302057973692172, 1237.4785220361964093>,
		<-2721.7475964839522931, 1115.3434150857556233, 1241.1341004452601737>,
		<-711.99363163820544287, 1113.9653658569463914, 1239.7560512164509419>,
		<-713.22223976959799074, -893.18194162859867902, 1238.527443085058394>,
		<-712.90481070357554927, -893.49937069462112049, -767.70868533511657006>,
		<-713.65531061695128301, 1112.3036868782005513, -766.95818542174083632>,
		<-2718.5600943257700237, 1112.155912927573354, -766.81041147111363898>
	}

	face_indices {
		12,
		<0, 1, 2>, 1, 0, 1,
		<3, 4, 5>, 1, 1, 1,
		<5, 6, 3>, 1, 1, 1,
		<3, 2, 1>, 1, 1, 0,
		<1, 4, 3>, 0, 1, 1,
		<6, 5, 0>, 1, 1, 1,
		<0, 7, 6>, 1, 1, 1,
		<2, 3, 6>, 1, 1, 1,
		<6, 7, 2>, 1, 1, 1,
		<1, 0, 5>, 0, 1, 1,
		<5, 4, 1>, 1, 1, 0,
		<2, 7, 0>, 1, 1, 1
	}
	inside_vector CameraSky
	translate <1716.181589446674252, -109.77740804847752543,
-235.56809340798210428>
}

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│ "There does not now, nor will there ever, exist a programming
│ language in which it is the least bit hard to write bad programs." ---
│ Flon's Axiom

Post a reply to this message

On 07/12/13 18:24, David Given wrote:
[...]
> 	face_indices {
> 		12,
> 		<0, 1, 2>, 1, 0, 1,

Arrgh --- I hadn't twigged that the texture values here are *integers*
--- indices into the texture list. Interpolation isn't done if you
supply a fractional value.

So instead I've wedged my texture values into the u channel of the uv
mapping, and am then doing this:

	object
	{
		mesh2
		{
			#include "/tmp/mesh.inc"
		}
		scale km

		uv_mapping texture
		{
			gradient x

			texture_map
			{
				[0.0 pigment { rgb <1, 0, 0> }]
				[1.0 pigment { rgb <0, 1, 0> }]
			}
		}
	}

Simple, easy, effective, and doesn't need face_indices at all.

In fact this has shown up a fundamental flaw in my logic, which is that
by using a simple linear range of textures like this I can't interpolate
from texture #0 to texture #10 without going through all the textures in
between, which would look a bit odd. So I'm going to have to rethink my
reasoning from the ground up.

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│ "There does not now, nor will there ever, exist a programming
│ language in which it is the least bit hard to write bad programs." ---
│ Flon's Axiom

Post a reply to this message

Am 07.12.2013 19:24, schrieb David Given:
> [...]
> On 07/12/13 13:52, clipka wrote:
>> There is indeed: While the documentation claims that the texture_list
>> must go between vertex_vectors and face_indices, the actual
>> implementation also allows it to be placed /before/ vertex_vectors.
>
> Not quite --- it needs this patch:
>
> diff --git a/source/backend/parser/parse.cpp
> b/source/backend/parser/parse.cpp
> index 7268519..5671853 100644
> --- a/source/backend/parser/parse.cpp
> +++ b/source/backend/parser/parse.cpp
> @@ -4123,7 +4123,6 @@ ObjectPtr Parser::Parse_Mesh2()
>                          }
>
>                          Parse_End();
> -                       EXIT
>                  END_CASE
>
>                  OTHERWISE

Dang, you're bloody well right.

Post a reply to this message

On 12/07/2013 03:02 PM, clipka wrote:
> Am 07.12.2013 19:24, schrieb David Given:
>> [...]
>> On 07/12/13 13:52, clipka wrote:
>>> There is indeed: While the documentation claims that the texture_list
>>> must go between vertex_vectors and face_indices, the actual
>>> implementation also allows it to be placed /before/ vertex_vectors.
>>
>> Not quite --- it needs this patch:
>>
>> diff --git a/source/backend/parser/parse.cpp
>> b/source/backend/parser/parse.cpp
>> index 7268519..5671853 100644
>> --- a/source/backend/parser/parse.cpp
>> +++ b/source/backend/parser/parse.cpp
>> @@ -4123,7 +4123,6 @@ ObjectPtr Parser::Parse_Mesh2()
>>                          }
>>
>>                          Parse_End();
>> -                       EXIT
>>                  END_CASE
>>
>>                  OTHERWISE
>
> Dang, you're bloody well right.
>

LOL ... so now you're going to change source to match docs ... right?

Post a reply to this message

Am 08.12.2013 13:11, schrieb James Holsenback:
> On 12/07/2013 03:02 PM, clipka wrote:
>> Am 07.12.2013 19:24, schrieb David Given:
>>> [...]
>>> On 07/12/13 13:52, clipka wrote:
>>>> There is indeed: While the documentation claims that the texture_list
>>>> must go between vertex_vectors and face_indices, the actual
>>>> implementation also allows it to be placed /before/ vertex_vectors.
>>>
>>> Not quite --- it needs this patch:
>>>
>>> diff --git a/source/backend/parser/parse.cpp
>>> b/source/backend/parser/parse.cpp
>>> index 7268519..5671853 100644
>>> --- a/source/backend/parser/parse.cpp
>>> +++ b/source/backend/parser/parse.cpp
>>> @@ -4123,7 +4123,6 @@ ObjectPtr Parser::Parse_Mesh2()
>>>                          }
>>>
>>>                          Parse_End();
>>> -                       EXIT
>>>                  END_CASE
>>>
>>>                  OTHERWISE
>>
>> Dang, you're bloody well right.
>>
>
> LOL ... so now you're going to change source to match docs ... right?

I guess so. A bit of flexibility in the syntax doesn't hurt.

Post a reply to this message

On 12/07/2013 10:57 AM, James Holsenback wrote:
> On 12/07/2013 08:52 AM, clipka wrote:
>> Am 07.12.2013 14:26, schrieb David Given:
>>
>>> I want the texture list to be in the Povray file, not in the machine
>>> generated include file, because it's source code. But the syntax appears
>>> to be insisting that the texture_list clause goes *between* the
>>> vertex_vectors and face_indices clause. In order to emit it there, my
>>> tool needs to know stuff about the structure of the Povray file that it
>>> really shouldn't know.
>>>
>>> I've tried defining the texture list with #declare, but that doesn't
>>> work because texture_list isn't an rvalue and can't be assigned to a
>>> variable.
>>>
>>> Is there any wrinkle of syntax that will allow me to get the texture
>>> list out of the include file?
>>
>> There is indeed: While the documentation claims that the texture_list
>> must go between vertex_vectors and face_indices, the actual
>> implementation also allows it to be placed /before/ vertex_vectors.
>>
>
> better? ... http://wiki.povray.org/content/Reference:Mesh2

should I roll back this change?

Post a reply to this message