 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <chrishuff-5CABFF.20002302032001@news.povray.org> , Chris
Huff <chr### [at] mac com> wrote:
> I think it could be done without too much trouble or code, just parse
> the pattern into a variable and implement a case in Parse_Pattern to
> handle pattern identifiers that would just copy the needed data. I don't
> see anything in the code that will prevent this being tacked on...but if
> this is going to be in 3.5, or even if the relevant code will be cleaned
> up, there isn't much of a reason to mess with it now.
Well, the problem is the way POV-Ray currently creates "classes" and
"objects". You inherit properties by placing all contents in a big
define and then the appear everywhere and explicit casting is used to
access the fields. Now, because when writing the code you can check
which pattern is valid in which context, you can of course cast a
pattern structure back to a texture, media or a pigment. But what
happens if it is just a plain pattern? Bad luck, you just accessed
unallocated memory!
As I said, one can go ahead and clean all this up and as said I have a
fairly far amount of work done on that (if you want, I can e-mail it to
you), but once all the nice cleanup is done, you still have to test it
because the changes you have to make to implement this in a clean way
are massive, reaching from lighting.cpp to media.cpp. The real problem
is the testing because you have to clean up the media, pigment and
texture parsing code at the same time - just take a look into
Parse_Pattern...
The good thing about this is that all the ugly casting goes away. You
even gain some memory by moving data to its appropriate place. However,
more remains to be done: The complex question of what constitutes a
"pattern" and what a "pigment". As you know, for some patterns like
checker you declare two colors along with the patterns while for others
you have to use a color map (referred to as Blend_Map inside the source
code). Unfortunately, access to it is not unambiguous inside the source
code. I was a bit surprised about this myself when seeing it the first
time, but in essence the whole pattern structure contains fields that
are misused all over the place For example the "next" pointer is
actually used by media only, and has nothing to do with patterns. I
have that cleaned up already, but then it just gets worse because this
is what actually brings the media code into the game.
Oh, and of course the patterns that aren't really patterns (like the
"average" pattern, see the docs) had to be fixed. Take a look at the
function pattern parse code in the current code base and you will know
what I mean. It works around the problem by simply copying a subset of
the pattern parsing code and for all practical purposes creates a
pattern only object.
Don't get me wrong: I do not say it is an impossible task, not even a
hard task, but it is an awful lot of work in a lot of parts of the code
if it isn't just supposed to be a quick hack (like so many things we had
to fix in MegaPOV code already).
And it is simply too easy to make some mistake, and such a mistake may
cause crashes only in a strange combination of texture, pigment, media
and normal. It would be a testing nightmare. So the premise is to
"never change a running system", especially if it is as essential as
this one! Nevertheless, for 4.0 this will all be fixed properly
anyway...
Thorsten
____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg
I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This is approximately (because it isn't complete or perfect) how it
should look like. Compare it with the current code and take a guess how
much work it is...
struct Pattern_Struct
{
unsigned short Type, Wave_Type, Flags;
int References;
SNGL Frequency, Phase;
SNGL Exponent;
WARP *Warps;
union
{
DENSITY_FILE *Density_File;
IMAGE *Pattern_Image;
VECTOR Gradient;
SNGL Agate_Turb_Scale;
short Num_of_Waves;
short Iterations;
short Arms;
struct
{
SNGL Mortar;
VECTOR Size;
} Brick;
struct
{
SNGL Control0, Control1;
} Quilted;
struct
{
DBL Size, UseCoords;
VECTOR Metric;
} Facets;
struct
{
VECTOR Form;
VECTOR Metric;
DBL Offset;
DBL Dim;
short IsSolid;
VECTOR *cv;
long lastseed;
VECTOR lastcenter;
} Crackle;
struct
{
VECTOR Slope_Vector, Altit_Vector;
short Slope_Base, Altit_Base;
SNGL Slope_Len, Altit_Len;
UV_VECT Slope_Mod, Altit_Mod;
} Slope;
struct
{
unsigned short Fn;
void *Data;
} Function;
PIGMENT *Pattern_Pigment;
} Vals;
};
enum PIGMENT_TYPE
{
NO_PIGMENT = 0,
COLOR_PIGMENT, // uses Colour
AVERAGE_PIGMENT, // uses Average_Map
UV_PIGMENT, // uses Blend_Map and Pigment
IMAGE_PIGMENT, // uses Image
PATTERN_PIGMENT // uses Blend_Map and TPat
};
struct Pigment_Struct
{
PIGMENT_TYPE Pigment_Type;
union
{
COLOUR Colour;
BLEND_MAP *Average_Map;
struct
{
BLEND_MAP *Blend_Map;
union
{
PIGMENT *Pigment;
TPATTERN *TPat;
};
};
IMAGE *Image;
};
};
enum NORMAL_TYPE
{
NO_NORMAL = 0,
IMAGE_NORMAL, // uses Image
PATTERN_NORMAL // uses TPat
};
struct Tnormal_Struct
{
NORMAL_TYPE Normal_Type;
SNGL Amount;
SNGL Delta;
union
{
IMAGE *Image;
TPATTERN *TPat;
};
};
struct Texture_Struct
{
TEXTURE *Next;
TEXTURE *Next_Material;
PIGMENT *Pigment;
TNORMAL *Tnormal;
FINISH *Finish;
TEXTURE *Materials;
int Num_Of_Mats;
};
struct Finish_Struct
{
SNGL Diffuse, Brilliance;
SNGL Specular, Roughness;
SNGL Phong, Phong_Size;
SNGL Irid, Irid_Film_Thickness, Irid_Turb;
SNGL Temp_Caustics, Temp_IOR, Temp_Dispersion,
Temp_Refract, Reflect_Exp;
SNGL Crand, Metallic;
RGB Ambient, Reflection_Max, Reflection_Min;
SNGL Reflection_Falloff;
int Reflection_Type;
SNGL Reflect_Metallic;
int Conserve_Energy;
};
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> it's a pigment_pattern because it's a pattern made from a pigment, not
because
> it's used in pigments.
Then the name feels out of order... it should be pattern_from_pigment, or
something. :) I don't know... I just don't like it... If the rest of you
feel comfy-fine with it, then OK, I'll put up with it...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I highly doubt that it works differently from the other patterns.
Is that a "no"?
> It's called "pigment_pattern" because it takes a pigment and turns it
> into a pattern. Makes perfect sense to me..."pattern" wouldn't, though.
> (What kind of pattern? What's this pigment doing here?)
It doesn't make sense to me... Especially when used in a "normal {}"
statement. "pattern" makes sense, since, well, it is a pattern. The pigment
would be there, being patternized... Hey! Maybe the keyword should be
"patternize"... OK, I'll shut up now.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Better might be to just get rid of it altogether, since there are now
> lots of better ways of doing most of what it can do. Not likely to
> happen now, though, for hysterical raisins.
Yep, POV is getting old and needs to be 4.0'd soon.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tony[B]" wrote:
> > it's a pigment_pattern because it's a pattern made from a
> > pigment, not because it's used in pigments.
>
> Then the name feels out of order... it should be
> pattern_from_pigment, or something. :) I don't know...
> I just don't like it... If the rest of you feel comfy-fine
> with it, then OK, I'll put up with it...
It's common for words to work like that. The last part describes what the
object is, and the first part describes what is special about it. Here's
some examples:
A mailbox is a box. It contains mails.
A race horse is a horse. It participates in races.
A horse race is a race. It is a race for horses.
Similary, a pigment_pattern is a pattern. The special thing about this
pattern is that it is made from a pigment.
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 28)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Similary, a pigment_pattern is a pattern. The special thing about this
> pattern is that it is made from a pigment.
<sigh> Your fish is coming along nicely, BTW.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tony[B]" wrote:
> Your fish is coming along nicely, BTW.
Ooh! Sounds good! :D
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 28)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
