First of all, thank you all for making such a nice ray tracer available.

Now, my problem.  I am writing a free program in Mac Cocoa for editing
cinematic adventure games.  I'm using POV to render the images for the
game.  I must generate a suite of scenes for the POV ray tracer to
render; the resulting images from which are incorporated into the
game.  The suite is fairly complex; it generates multiple scenes for
different locations, orientations, lighting conditions, etc.  All of
this already works.

The images must be rendered at a variety of image sizes.  For
example, panoramic views are rendered using a cylindrical camera
with a very wide image, while close-up views are rendered with a
perspective view and a relatively small image size.  There are also
partial panoramas and the possibility of close-up views of different
size.  The size is determined within my program.  It's particularly
important that I correlate the size with the camera's aspect ratio.

The POV license is fairly adamant about not hiding the POV user
interface.  This is OK; an acceptable solution is to let the user
render the images using the rendering queue.

However, I would like to be able to associate an image size with
a particular .pov file that I generate.  Is there any way to do
this?  I don't know where the sizes are stored when they are set
in the user interface, the resource fork perhaps?

Any help would be appreciated.

Post a reply to this message

Eric Pepke wrote:
>However, I would like to be able to associate an image size with
>a particular .pov file that I generate.  Is there any way to do
>this?  I don't know where the sizes are stored when they are set
>in the user interface, the resource fork perhaps?

Well, where else could they be stored together with the file?  Apparently
you are a programmer, so you can just get the POV-Ray source code and find
out the exact details of the preference format there. It is
well-documented.

   Thorsten

Post a reply to this message

Thorsten wrote:

> Eric Pepke wrote:
> 
>>However, I would like to be able to associate an image size with
>>a particular .pov file that I generate.  Is there any way to do
>>this?  I don't know where the sizes are stored when they are set
>>in the user interface, the resource fork perhaps?
>>
> 
> Well, where else could they be stored together with the file?  Apparently
> you are a programmer, so you can just get the POV-Ray source code and find
> out the exact details of the preference format there. It is
> well-documented.


That's a good question.  I would think that they might be stored in a
file with the same name and a different extension.  However, when I
create a .pov file with the user interface, it doesn't appear to do
that.  By playing around with cp, though, I noticed that the .pov
file did have a resource fork.  Looking at the resource fork with
ResEdit, I noticed two resources with type POVR.  The one with ID
3000 appeared to be the one with the information.

Following your advice, however, I got the POV-Ray source code and
searched for "Preference" and "Setting" (both are used in the POV-Ray
user interface).  I found a piece of code that executed a
WritePreferencesResource that used the TextDocument.renderSettings to
keep the render settings.  This, of course, is a Collection, which is
a Mac Carbon Core thingie.  I went through a bunch of stuff trying to
figure out the use of kFilePrefs_CollectionKind versus (which is 'FPrf')
which says it's used in kFPData_CollectionKind, but it isn't, and
kPrefsCollectionKind which is actually 'Kind', so at this point I gave
up and went back to WritePreferencesResource, which I found in the
framework subdirectory, and it turns out the kind doesn't matter much,
because it uses a FlattenCollectionToHdl to get the data to save to the
resource.  This, of course, is Mac-specific and basically has an
internal format.  However, it's likely that Apple will maintain backward
compatibility.  So, at this point I gave up trying to find where the
format is well documented and just looked through the resource to find
the values for width and height.  A 16-bit height turns out to start at
address 31A, and a 16-bit width turns out to start at address 322.  This
is probably the low word of a 32-bit number, but it doesn't matter for
the resolutions I'm using.


I went back and looked at the Read Me First! file, the How To Compile!
file, the various text files in the subdirectories, and I could still
find no documentation.

So, in the absence of being able to find this documentation, I guess I'm
stuck with taking a snapshot of the resource set up correctly, patching
in the width and height programmatically, and saving that as a resource.

Post a reply to this message

In article <3E1### [at] acmorg> , Eric Pepke <epe### [at] acmorg>  wrote:

> That's a good question.  I would think that they might be stored in a
> file with the same name and a different extension.

Mean mean so that preferences are lost when the users moves the file?  Also
some fools from Next may abandon some of the most outstanding features of
the Mac, that does not mean everybody has to follow Apple like lemmings ;-)

> Following your advice, however, I got the POV-Ray source code and
> searched for "Preference" and "Setting" (both are used in the POV-Ray
> user interface).  I found a piece of code that executed a
> WritePreferencesResource that used the TextDocument.renderSettings to
> keep the render settings.  This, of course, is a Collection, which is
> a Mac Carbon Core thingie.

As you know, you can call any Carbon function in Mac OS X...

>  I went through a bunch of stuff trying to
> figure out the use of kFilePrefs_CollectionKind versus (which is 'FPrf')
> which says it's used in kFPData_CollectionKind, but it isn't, and
> kPrefsCollectionKind which is actually 'Kind', so at this point I gave
> up and went back to WritePreferencesResource, which I found in the
> framework subdirectory, and it turns out the kind doesn't matter much,
> because it uses a FlattenCollectionToHdl to get the data to save to the
> resource.  This, of course, is Mac-specific and basically has an
> internal format. However, it's likely that Apple will maintain backward
> compatibility.

No, you are on the completely wrong track here.  The format is guaranteed by
Apple to be readable and writable by the appropriate system functions.
Nobody should even care what it looks like internally.  BTW, the "More is
Better" Apple DTS sample code actually uses collection based preferences
format also used by POV-Ray.

> So, at this point I gave up trying to find where the
> format is well documented and

Because you are still on the wrong track.  You are not looking for the
format of the Collection resource on disk because the operating system
already provides you with services to read and write it.  So you are looking
for the operating system functions to use the data once read via the
appropriate functions.  You found the POV-Ray functions that read and write
preferences, so I am surprised you missed it.

> just looked through the resource to find
> the values for width and height.  A 16-bit height turns out to start at
> address 31A, and a 16-bit width turns out to start at address 322.  This
> is probably the low word of a 32-bit number, but it doesn't matter for
> the resolutions I'm using.

Oh my god!  This will break instantly, and your speculation is completely
pointless given that you can find the truth in the source code so easily.
Do it properly (the same way as POV-Ray does) and you don't have to use such
hacks at all.  This is not a hacking contest, it is a read the documentation
contest!

> I went back and looked at the Read Me First! file, the How To Compile!
> file, the various text files in the subdirectories, and I could still
> find no documentation.

Well, those files tell you that the documentation exists in form of comments
in the source code.  And if you look you will easily find where the
collection resource is filled with content.  From there is really isn't hard
to track it back find the comments which exist for each and every collection
entry...

> So, in the absence of being able to find this documentation, I guess I'm
> stuck with taking a snapshot of the resource set up correctly, patching
> in the width and height programmatically, and saving that as a resource.

You are just on the completely wrong track, and that is where your trouble
comes from.  Some hacking won't get you anywhere, but actually following the
POV-Ray Mac source code together with knowing what system functions do will
help you a lot more and get you where you want much, much faster!

    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

Thorsten, just what exactly is your problem with me?  As far as I know,
I've never even met you, so what could I have done to you?  And I said
up front that I appreciate your having released such a fine ray tracer.
And I'm trying to add value to it.

I'm doing the best I can, given that I'm dealing with a bunch of source
code that I didn't write and don't understand, and that I'm a Cocoa
guru but a Carbon novice.  I don't want to get into an argument with
you about the "right" way to do this, smilies or no; I'm just trying
to figure out how it is done, and given that Open... doesn't work, I
don't have a lot of prima facie evidence that everything is done in a
way that I'd consider right and guaranteed not to break.  I don't have
CodeWarrior to do searches for me, and I have to convert every source
file with a Perl script before I can meaningfully run grep on it.

If you don't want to point me in the direction of what source files
to look into to figure out the format of this resource, then that's
fine, but just *say so*.  And I'll get on with it and not bother asking
questions here and everyone will be happy.

Post a reply to this message

Eric Pepke wrote:
>Thorsten, just what exactly is your problem with me?  As far as I know,
>I've never even met you, so what could I have done to you?  And I said
>up front that I appreciate your having released such a fine ray tracer.
>And I'm trying to add value to it.

I have no problem with you. I am simply unable to see reason in the way you
go about finding out what you want to know.

>CodeWarrior to do searches for me, and I have to convert every source
>file with a Perl script before I can meaningfully run grep on it.

See, this is one of the points that I don't understand.  The source files
are plain text, so searching and navigating in them with any editor is the
most trivial thing on the planet. And you mentioned using "cp" to figure
out that there is a resource fork while all you need is a resource editor.
Why a perl script and a command-line tool to do the most basic stuff?  I
just don't get what you want to do. From what you say you are looking for
compared to what you do find it, to me it seems you are using cannons to
shoot at brids!?!

>If you don't want to point me in the direction of what source files
>to look into to figure out the format of this resource, then that's
>fine, but just *say so*.  And I'll get on with it and not bother asking
>questions here and everyone will be happy.

I just don't know how to help you. You found the functions
Read/WritePreferencesResource in PreferencesUtils.cp.  And you know that
POV-Ray stores a Carbon Collection resource.  But you also said you looked
for a documentation of the Collection resource format in POV-Ray also you
already know it comes from a system function. So why should a system fromat
be documented inside POV-Ray?

You have also seen the Get/SetCollectionItemValue functions in
PreferencesUtils.cp.  So you know how to read the resource, how to write
it, how to get and how to set values.  What do you need from me to help
you? Obviously you have a reason to access the raw resource, but I don't
get why...

   Thorsten

Post a reply to this message

This is kind of an old post, but I have to get this off my chest (or fingers...
this is the Internet, after all ;) ).

Thorsten's furious key-hammering produced this:
>>Thorsten, just what exactly is your problem with me?
> 
> I have no problem with you.

I'm not sure if you're really aware of this, Thorsten, but many of your posts
come off sounding very harsh.  I'm sure you don't intend for your posts to read
as such, but it can make people think that you're trying to start a flame war
rather than have a civilized conversation.

Followups set to povray.off-topic.

-- 
/*^*/light_source{100*<-5,2,-5>2}#macro I(i,n)#while(strlen(i)>=n)#local A=asc(
substr(i,n,1));#local a=asc(substr(i,n+1,1));cylinder{<div(A,8)-12,mod(A,8)-4,4
><div(a,8)-12,mod(a,8)-4,4>,0.1pigment{rgb z}}#local n=n+2;#end#end I("ScUe[]"1
/*<*/)I("mkmtlttk"1)//@_$#!,:<"Thhis polysig brought to you by Ian Burgmyer :)"

Post a reply to this message