Hi,
I would like to write small patch - that will change all materials in a 
given object (see also my question in newusers 
Message-ID: <Xns95D941FDFD3F8raf256com@203.29.75.35>)

I have complex object like:

#declare TheObject=
union {
  sphere { ... material{...} }
  sphere { ... material{...} }
  union { 
     box { ... material... }
     box { ... material... }
  }
}

and now I would like to discard all pervious materials/textures from all 
objects inside TheObject, and apply to entire object some given material.

I need to do it in a program, not manualy change the code of "TheObject" 
(since TheObject is produced by external program and it would be a 
problem).

I would like to have syntax like:

object { 
  MyObject
  forget_previous_materials
  material { pigment { rgb 1 } } 
}

or

object { 
  MyObject
  force_material { pigment { rgb 1 } } 
}


I think that keyword should result in function walking entire tree of given 
object (all it-s subojbects, down to all primitives, and replace pointers 
to materials in all of them to point to a new texture).

Where should I start? Is there some tutorial for povray programming? 

Resulting code will be donated to PovRAY.
  

-- 
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics

Post a reply to this message

> I would like to have syntax like:
> 
> object { 
>   MyObject
>   forget_previous_materials
>   material { pigment { rgb 1 } } 
> }
> 
> or
> 
> object { 
>   MyObject
>   force_material { pigment { rgb 1 } } 
> }

> I think that keyword should result in function walking entire tree of
> given object (all it-s subojbects, down to all primitives, and replace
> pointers to materials in all of them to point to a new texture).

It would be quite easy. You would just have to add a bit to the parser
to recognise that token and free the texture/material (recursively down
an object's siblings and children if necessary), and then let the new
material be parsed as normal.

> Where should I start? Is there some tutorial for povray programming? 
You should start in parse.cpp and tokenize.cpp, and their associated
header files. There is (to my knowledge) no tutorial in POV-Ray
programming, for a good reason. The code is very nasty and hacky
(especially the parser) and should not be touched by anyone who wants to
escape with his sanity intact. Possibly when Hell freezes over and
POV-Ray 4 is released, the code will be so nice and modular that you
won't even need a tutorial!

Daniel

Post a reply to this message

On 9 Jan 2005 15:54:17 -0500, "Rafal 'Raf256' Maj" <spa### [at] raf256com> wrote:
> I need to do it in a program

The question is, which program? Since your (suggested) change would not remove
all memory allocations, the parsing/scene building could be not optimal. And
you could get not perfectly optimized build of the renderer. I suggest other
solution. I expect the writer application is open source (one of modelers,
right?). I imagine it could be possible to modify it's export routine from:

  #declare Object$(ID) = object{ ...AAA... pigment{ ...BBB... } }

to

  #macro PigObject$(ID)() ...BBB... #end
  #macro Object$(ID)() ...AAA... pigment{ PigObject$(ID)() } #end

(where $(ID) is some internal string or integer identificator of the object)

then you could simply add object with modeler testuring:

  object{ ObjectMyObject() }

or give it own texturing

  #macro PigObjectMyObject() red 1 #end
  object{ ObjectMyObject() }

You can extend this from pigments to finishes, texturing, materials etc. etc.
I hope that's clear and readable what I meant.

ABX

Post a reply to this message

abx### [at] abxartpl news:0jb4u0dnv9cduq1bg86sfkrl0h1p2oanpc@4ax.com

>> I need to do it in a program
> The question is, which program? Since your (suggested) change would

I ment: to write a patch for MegaPov 1.1 (since this is renderer I use 
currently for this task in with I need to strip textures).

> not remove all memory allocations, the parsing/scene building could be
> not optimal. And you could get not perfectly optimized build of the
> renderer. 

strip_textures should walk entire tree of given object, and free memory 
used by textures/materials of each part of this object. AFAIK after that 
operation object would behave as if there where no materials declared 
before, so applying final texture to it will effect all objects inside 
TheObject.

Hmm where exacly I could add my strip_materials token? And where to put 
function StripMaterials() - and how to access in it pointer to currently 
parsed object?

object { 
  TheObject // complex union for example

  strip_textures // I want here to call StripTextures() and give to it
    	// pointer to current object. BTW. afaik "current object" is a copy
    	// of TheObject, since Pov-RAY doesnt yet support referencing objects
    	// (instead of mesh and mesh2) - with actualy is good in this case
  
  material { ... } // since now my object has no material applyed, so this
    	// material will apply to entire object including all it parts?

}

> I suggest other solution. I expect the writer application is
> open source (one of modelers, right?). I imagine it could be possible
> to modify it's export routine from: 
>   #declare Object$(ID) = object{ ...AAA... pigment{ ...BBB... } }

It was ofcourse my first idea. The object is a 3d MAX object imported 
through Poseray. Doing such changes manualy, to probably 100 or more 
objects - isnt so easy. Writting script to do it automaticly hmm I dont 
know... I think also that strip_materials patch will be usable so why not 
implement it.



-- 
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics

Post a reply to this message

On 10 Jan 2005 02:51:40 -0500, "Rafal 'Raf256' Maj" <spa### [at] raf256com> wrote:
> > > I need to do it in a program
> > The question is, which program? Since your (suggested) change would
>
> I ment: to write a patch for MegaPov 1.1 (since this is renderer I use 
> currently for this task in with I need to strip textures).

I meant reader vs. writer.

> > not remove all memory allocations, the parsing/scene building could be
> > not optimal. And you could get not perfectly optimized build of the
> > renderer. 
>
> strip_textures should walk entire tree of given object, and free memory 
> used by textures/materials of each part of this object.

Which clearly means defragmentation of memory in larger scenes. I cannot
predict how it could influence final performance but it would definietly
happen.

> Hmm where exacly I could add my strip_materials token?

http://abx.art.pl/pov/patches/patches.php?Key=New+keywords

> Writting script to do it automaticly hmm I dont know...

If PoseRay is closed source then definietly. Since it is exported I imagine
there nothing advanced like #macros so dummy parsing and rearranging with
smart scripting language would be much more efficient than wasting time for
(de)allocation memory during parsing/rendering.

ABX

Post a reply to this message

abx### [at] abxartpl news:cbm4u0dpjk4f5v2ubf9qv6s29v544c0hpn@4ax.com

> Which clearly means defragmentation of memory in larger scenes. I
> cannot predict how it could influence final performance but it would
> definietly happen.

I was told that fragmentation of memory was [a notacible] problem only on 
16 bit systems. Perhaps a bit in DOS 32 DPMI or some old win98, but not on 
modern OS. But,

> than wasting time for (de)allocation memory during parsing/rendering.

ok, a better idea:

object {
  skip_materials
  MyObject
  material { ... } // ((1))
}
#undef TheObject // ((2))


When creating a copy of MyObject, all textures will not be copy, they will 
be replace with no-texture (NULL afaik?) instead, therefore they will use 
the material ((1)). If one realy want to save memory then ((2)) line will 
do it. So, where is make-copy-of-object-in-object{}-statemenr placed? I 
should indicate that current object has "skip_materials" flag by some 
global variable or is tere a nicer way recommended for it?

-- 
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics

Post a reply to this message

On 10 Jan 2005 11:27:47 -0500, "Rafal 'Raf256' Maj" <spa### [at] raf256com> wrote:
> I was told that fragmentation of memory was [a notacible] problem only on 
> 16 bit systems. Perhaps a bit in DOS 32 DPMI or some old win98, but not on 
> modern OS.

Whatever OS it would be, there is not many comparable applications which swaps
on 1GB of RAM, I think.

ABX

Post a reply to this message

abx### [at] abxartpl news:5nb5u05jf8n4j8dalofos6ill79kk3njst@4ax.com

> Whatever OS it would be, there is not many comparable applications
> which swaps on 1GB of RAM, I think.

The second syntax should work nice (for everyone), as for me - this scenes 
uses 10-100 mb peak memory so its not a problem, the problem is how to 
implement it :)

-- 
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics

Post a reply to this message

Wasn't it Rafal 'Raf256' Maj who wrote:
>
>I need to do it in a program, not manualy change the code of "TheObject" 
>(since TheObject is produced by external program and it would be a 
>problem).

If you arrange for TheObject to be in a separate include file, it might
be easier to use a simple external program to produce a copy with *all*
the textures removed. I'd suggest using Perl or Python.

The program would have to be able to count the depth of "{" to "}"
nesting and be able to recognise the keywords "material", "texture",
"pigment", "normal" and "finish". When it finds such a keyword it skips
it, and skips the following characters until the curly-bracket depth
gets back to the current level.

All the textures you want to apply would be held in the scene file that
#includes the stripped file.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

"Rafal 'Raf256' Maj" <spa### [at] raf256com> wrote:
> Hi,
> I would like to write small patch - that will change all materials in a
> given object (see also my question in newusers
> Message-ID: <Xns95D941FDFD3F8raf256com@203.29.75.35>)

Hi Rafal,

Great idea. I understand very well the need of such a mechanism because
recently I had problems with changing textures of object translated with
Poseray. It would be great if we could overwrite textures after object is
defined.
However I think there are some difficulties which may appear with this task.
When we look close to file exported by Poseray it is only one mesh
containing all objects/layers/meshes from imported 3ds or dxf file. It is
textured internally per triangle with usage of texture indexes. It looks
like this:

....
//Materials
#include "P406_pov_mat.inc"

//Geometry
#declare P406=mesh2{
vertex_vectors{
9934,
<-76.68591,72.47195,-205.5871>,
<-77.89292,74.35229,-201.6031>,
<-71.15259,72.03568,-209.5126>,
....
texture_list{
20,
texture{P406_light_material},
texture{P406_logo__material},
texture{P406_stear_material},
texture{P406_lig01_material},
texture{P406_numbe_material},
texture{P406_glass_material},
texture{P406_dashb_material},
texture{P406_rims_material},
texture{P406_shift_material},
texture{P406_handb_material},
texture{P406_rimho_material},
texture{P406_seats_material},
texture{P406_log01_material},
texture{P406_lig02_material},
texture{P406_chass_material},
texture{P406_tires_material},
texture{P406_mirro_material},
texture{P406_mir01_material},
texture{P406_rubbe_material},
texture{P406_body_material}
}
face_indices{
14444,
<1,48,0>,0,
<3,44,45>,0,
<3,2,44>,0,
....
<62,56,95>,1,
<74,56,62>,1,
<76,60,128>,1,

The last numbers are texture indexes - according to texture list order.

So what is worth consideration in my opinion:

1. A pointer to texture is connected to every triangle in the mesh so you
have to find them all in object tree - what probably is not so difficult
but may be memory consuming - mesh in the example above has 14444 triangles
- imagine that we are creating 1000 copies of this mesh replacing each time
the textures (this is what we want) what gives us 14444000 pointers to the
textures - if I correctly understand Povray internal organisation of
objects.

2. It would be very useful if we could change only one defined texture in
such an object. For example recently I needed to replace only car paint
colour without changing the rest of the textures. So it would be very nice
if your patch could replace pointed texture with new one instead of just
removing all texture definitions (if removed all we cannot get right
texturing with objects containing many different parts - like the car
above)

Greetings,
Przemek

Post a reply to this message