aqsis-development — Development related discussion.

[Aqsis-development] a littel off topic: how phong with aqsis ?

[J. S. <mu...@we...>]

Hi,

I am a programmer of white_dune, a open source 3d modeller and animation
tool.
It can write a .rib file to be used with aqsis, but i can not find out
how to create a phong effect like
the screenshot in the attachment.
I tried the metal and shinymetal surfaces on the mesh of a sphere, but
all i got was the image of
a light or gray sphere 8-(

Can someone help me, how to create a phong-like effect with aqsis ?

so long
MUFTI

[Aqsis-development] RIB commands for material control

[J. S. <mu...@we...>]

Hi,

I am a programmer of white_dune (https://wdune.ourproject.org), a 3d
modeller and animation tool,
that can write .RIB files usable with aqsis.

I want to ask, what are the RIB commands for material control, e.g.
mirroring.
I want to extend white_dune with special commands for material control.

so long
MUFTI

Re: [Aqsis-development] Switchover to github

[Nathan V. <ce...@ce...>]

Speaking of which, if any of you are curious:
http://psychopath.io

The broad architecural decisions are fairly stable at this point, I think.
It's mainly about adding missing features and iterating on the
quality/completeness of the code base now.

(I think...)

--Nathan
On Aug 25, 2015 12:04 AM, "Chris Foster" <chr...@gm...> wrote:

> On Tue, Aug 25, 2015 at 8:02 AM, Matthias Baas <mat...@gm...>
> wrote:
> > Is there actually any renewed development activity going on?
>
> Nothing coming from me.  At this stage I consider the aqsis codebase
> to be a useful place to get bits and pieces from, and hopefully
> there's a bunch of things in there which are educational.  However the
> world has truly moved on from the underlying lighting technology and I
> think this has been clear for at least several years.  With that in
> mind and a _lot_ of other things to work on, I said goodbye to the
> codebase a few years ago.  Of course, it would be possible to
> modernize things with sufficient effort, but I think that would end up
> as an entirely new renderer.
>
> ~Chris
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Aqsis-development mailing list
> Aqs...@li...
> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>

Re: [Aqsis-development] Switchover to github

[Chris F. <chr...@gm...>]

On Tue, Aug 25, 2015 at 8:02 AM, Matthias Baas <mat...@gm...> wrote:
> Is there actually any renewed development activity going on?

Nothing coming from me.  At this stage I consider the aqsis codebase
to be a useful place to get bits and pieces from, and hopefully
there's a bunch of things in there which are educational.  However the
world has truly moved on from the underlying lighting technology and I
think this has been clear for at least several years.  With that in
mind and a _lot_ of other things to work on, I said goodbye to the
codebase a few years ago.  Of course, it would be possible to
modernize things with sufficient effort, but I think that would end up
as an entirely new renderer.

~Chris

Re: [Aqsis-development] Switchover to github

[Matthias B. <mat...@gm...>]

Hi there,

it's been a while!
To add to Chris' list: Depending on your monitor settings, the dark grey
on black can be a bit challenging to read.

Is there actually any renewed development activity going on? (as it has
been rather quiet for quite some time) What direction does this go?
I have just been to Siggraph and it's all about path tracing these days.
Even Pixar have essentially retired Reyes and turned PRMan into a
raytracer by now (and meanwhile, they also have a free non-commercial
version of PRMan and there's an integration plugin even for Blender).
That and the other free rendering solutions out there (mainly Blender's
Cycles, I suppose) probably make it harder than ever finding a niche for
Aqsis...

Cheers,

Matthias


On 23.08.15 02:26, Chris Foster wrote:
> Hi Paul,
> 
> I'm still lurking, good call on all of that.  I think the new site
> looks better than any of the old ones we had.
> 
> A few mostly obvious things:
> * There's a gallery link, but no content
> * The Lorem Ipsum in the sidewall widget
> * The dates on the converted posts are wrong.
> * A simple download link in the bar at the top would make sense (just
> a link to the github releases page would probably do, provided we
> actually tagged some releases in a form recognized by github and
> uploaded the binaries there.)
> * I remember writing something in the manual about PBGI, but I can't
> seem to find it on the site.  It's still in the source at
> doc/manual/user/user_guide/pbgi/point_based_gi.rst, so I'm not sure
> where it went to.
> 
> Cheers,
> ~Chris
> 
> On Sun, Aug 23, 2015 at 7:58 AM, Paul Gregory <aq...@gm...> wrote:
>> Hello All,
>>
>> If anyone is still listening on this list, just wanted to send notification
>> that I've transitioned Aqsis from SourceForge to Github, and moved the
>> website to github pages using Jekyll.
>>
>> It was quite a job, bigger than I thought and unfortunately mostly manual,
>> but I think I've got most of the important stuff over for now. In case
>> anyone isn't aware, github pages is a 'static' web site system that github
>> offers, based on Jekyll. It allows you to store your website content in a
>> special branch of your project repo, gh_pages. It runs Jekyll over the
>> contents every time a push to that branch is done, and serves the static
>> content.
>>
>> I've transitioned the basic site, two recent blog posts from Chris Foster,
>> two tutorials, and the entire user manual.
>>
>> I'm looking for people to help out with the following:
>>
>> 1) QA the new site and fill in bugs in the issue tracker on github to
>> improve the content and the quality.
>> 2) More importantly, help out with the upkeep of the site.
>>
>> I've used a fairly straightforward configuration, most of it is quite
>> obvious with the possible exception of the user manual, which uses some
>> trick with Jekyll to make it automatic based on the file structure. I will
>> document it at some point, but in the meantime, if anyone volunteers to
>> help, I'd be happy to explain.
>>
>> BTW: http://www.aqsis.org is redirected to the github site now.
>>
>> Cheers
>>
>>
>> Paul
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Aqsis-development mailing list
>> Aqs...@li...
>> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>>
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Aqsis-development mailing list
> Aqs...@li...
> https://lists.sourceforge.net/lists/listinfo/aqsis-development
> 

Re: [Aqsis-development] Switchover to github

[Chris F. <chr...@gm...>]

Hi Paul,

I'm still lurking, good call on all of that.  I think the new site
looks better than any of the old ones we had.

A few mostly obvious things:
* There's a gallery link, but no content
* The Lorem Ipsum in the sidewall widget
* The dates on the converted posts are wrong.
* A simple download link in the bar at the top would make sense (just
a link to the github releases page would probably do, provided we
actually tagged some releases in a form recognized by github and
uploaded the binaries there.)
* I remember writing something in the manual about PBGI, but I can't
seem to find it on the site.  It's still in the source at
doc/manual/user/user_guide/pbgi/point_based_gi.rst, so I'm not sure
where it went to.

Cheers,
~Chris

On Sun, Aug 23, 2015 at 7:58 AM, Paul Gregory <aq...@gm...> wrote:
> Hello All,
>
> If anyone is still listening on this list, just wanted to send notification
> that I've transitioned Aqsis from SourceForge to Github, and moved the
> website to github pages using Jekyll.
>
> It was quite a job, bigger than I thought and unfortunately mostly manual,
> but I think I've got most of the important stuff over for now. In case
> anyone isn't aware, github pages is a 'static' web site system that github
> offers, based on Jekyll. It allows you to store your website content in a
> special branch of your project repo, gh_pages. It runs Jekyll over the
> contents every time a push to that branch is done, and serves the static
> content.
>
> I've transitioned the basic site, two recent blog posts from Chris Foster,
> two tutorials, and the entire user manual.
>
> I'm looking for people to help out with the following:
>
> 1) QA the new site and fill in bugs in the issue tracker on github to
> improve the content and the quality.
> 2) More importantly, help out with the upkeep of the site.
>
> I've used a fairly straightforward configuration, most of it is quite
> obvious with the possible exception of the user manual, which uses some
> trick with Jekyll to make it automatic based on the file structure. I will
> document it at some point, but in the meantime, if anyone volunteers to
> help, I'd be happy to explain.
>
> BTW: http://www.aqsis.org is redirected to the github site now.
>
> Cheers
>
>
> Paul
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Aqsis-development mailing list
> Aqs...@li...
> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>

[Aqsis-development] Switchover to github

[Paul G. <aq...@gm...>]

Hello All,

If anyone is still listening on this list, just wanted to send notification
that I've transitioned Aqsis from SourceForge to Github, and moved the
website to github pages using Jekyll.

It was quite a job, bigger than I thought and unfortunately mostly manual,
but I think I've got most of the important stuff over for now. In case
anyone isn't aware, github pages is a 'static' web site system that github
offers, based on Jekyll. It allows you to store your website content in a
special branch of your project repo, gh_pages. It runs Jekyll over the
contents every time a push to that branch is done, and serves the static
content.

I've transitioned the basic site, two recent blog posts from Chris Foster,
two tutorials, and the entire user manual.

I'm looking for people to help out with the following:

1) QA the new site and fill in bugs in the issue tracker on github to
improve the content and the quality.
2) More importantly, help out with the upkeep of the site.

I've used a fairly straightforward configuration, most of it is quite
obvious with the possible exception of the user manual, which uses some
trick with Jekyll to make it automatic based on the file structure. I will
document it at some point, but in the meantime, if anyone volunteers to
help, I'd be happy to explain.

BTW: http://www.aqsis.org is redirected to the github site now.

Cheers


Paul

Re: [Aqsis-development] Free non-commercial PRMan

[Alistair Leslie-H. <les...@ho...>]

That is cool.

Now, If only they would release an updated RI Spec. 


From: Paul Gregory 
Sent: Tuesday, March 24, 2015 7:19 AM
To: Development related discussion 
Subject: [Aqsis-development] Free non-commercial PRMan

http://renderman.pixar.com/view/get-renderman


Aqsis-development mailing list
Aqs...@li...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Aqsis-development] Free non-commercial PRMan

[Paul G. <pgr...@aq...>]

http://renderman.pixar.com/view/get-renderman

Re: [Aqsis-development] Possibility of Changing Object State, Dynamically

[Chris F. <chr...@gm...>]

Right, thanks for the details.

On Wed, Oct 15, 2014 at 12:36 AM, Gabriel <gn...@gm...> wrote:
> Hi Chris,
>
> basically I have simulated granular material  which I want to render this
> could be of any shape (most generally meshs)
> but for the start I have only spheres, I have a million spheres which all
> have a position and orientation over several frames.

Do you need to see details of individual spheres?  If not, RiPoints is
definitely the way to go.  (Obviously this won't work for general
meshes.)

> I can now write for each frame a RIB file to render the spheres. I was
> interested in the best possible way of doing this with a RIB file.
> I thought about making instances of all spheres first and then specifying
> multiple frames in the RIB file, where in each frame all spheres are
> instanced and transformed accordingly, that would save memory, but
> unfortunately the RIB specification of RiObjectInstance only allows ids up
> to 65535.

This shouldn't be a problem - aqsis supports ids up to the size of an
int, and also supports arbitrary string names for instances.
Apart from that, can't you just have a single sphere instance, and
repeat it one million times, once for each sphere.

> So the only way I see so far for the RIB specification is to specify in each
> frame all objects and transformations instead of trying to reuse some
> instance...

In this case I really think instancing isn't going to be much use,
because each piece of geometry is so simple.  You will get useful
compression by using binary RIB (along with faster parsing), but I
think a big win would be to use RiPoints instead of spheres.  That way
you can have a /single/ call to RiPoints, which results in a far more
compact geometry representation inside the renderer, and will give you
a huge improvement in render times.

If that doesn't do what you need, you may be stuck with RiSphere.  If
you like, paste in a typical chunk of your RIB data and we'll see
where there's anything that can be done to optimize it.

~Chris

[Aqsis-development] Possibility of Changing Object State, Dynamically

[Gabriel <gn...@gm...>]

Hi Chris,

basically I have simulated *granular material * which I want to render 
this could be of any shape (most generally meshs)
but for the start I have *only spheres*, I have *a million spheres 
*which all have a position and orientation over several frames.

I can now write for each frame a RIB file to render the spheres. I was 
interested in the best possible way of doing this with a RIB file.
I thought about making instances of all spheres first and then 
specifying multiple frames in the RIB file, where in each frame all 
spheres are instanced and transformed accordingly, that would save 
memory, but unfortunately the RIB specification of RiObjectInstance only 
allows ids up to 65535.
So the only way I see so far for the RIB specification is to specify in 
each frame all objects and transformations instead of trying to reuse 
some instance...

With Pov-Ray for example reusing objects and setting a new 
transformation is possible  :-)

is this correct? or is there some better approach =)?

Thanks a lot!
Gabriel


On 10/14/2014 02:02 PM, aqs...@li... 
wrote:
> Send Aqsis-development mailing list submissions to
> 	aqs...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/aqsis-development
> or, via email, send a message with subject or body 'help' to
> 	aqs...@li...
>
> You can reach the person managing the list at
> 	aqs...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Aqsis-development digest..."
>
>
> Today's Topics:
>
>     1. Re: Possibility of Changing Object State	Dynamically
>        (Chris Foster)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 14 Oct 2014 12:30:33 +1000
> From: Chris Foster <chr...@gm...>
> Subject: Re: [Aqsis-development] Possibility of Changing Object State
> 	Dynamically
> To: Development related discussion
> 	<aqs...@li...>
> Message-ID:
> 	<CAJ...@ma...>
> Content-Type: text/plain; charset=UTF-8
>
> Hi Gabriel,
>
> On Tue, Oct 14, 2014 at 1:54 AM, Gabriel <gn...@gm...> wrote:
>> Another concern:
>>
>> I have seen that there is RiObjectInstance which would let me define all
>> geometry first and then later apply transformations on these objects in
>> EACH Frame ...
>> the problem RiObjectInstance only accepts ID's up to 65535,
>> I need ids up to millions :-) hm...
>> Is there any way of reusing geometry and transfrom them from each frame to
>> another instead of having multiple huge RIB files for each Frame (in which
>> all Spheres are defined seperately)
> That sounds like a roundabout way to get what you want.  It's a bit
> hard to know what to suggest without knowing a bit more about the type
> of scene you're trying to render.  Perhaps you can give a bit more
> detail?  For example, if your spheres are small you might consider
> RiPoints instead of a big list of independent spheres.
>
> Cheers,
> ~Chris
>
>
>
> ------------------------------
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
>
> ------------------------------
>
> _______________________________________________
> Aqsis-development mailing list
> Aqs...@li...
> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>
>
> End of Aqsis-development Digest, Vol 79, Issue 5
> ************************************************

Re: [Aqsis-development] Possibility of Changing Object State Dynamically

[Chris F. <chr...@gm...>]

Hi Gabriel,

On Tue, Oct 14, 2014 at 1:54 AM, Gabriel <gn...@gm...> wrote:
> Another concern:
>
> I have seen that there is RiObjectInstance which would let me define all
> geometry first and then later apply transformations on these objects in
> EACH Frame ...
> the problem RiObjectInstance only accepts ID's up to 65535,
> I need ids up to millions :-) hm...
> Is there any way of reusing geometry and transfrom them from each frame to
> another instead of having multiple huge RIB files for each Frame (in which
> all Spheres are defined seperately)

That sounds like a roundabout way to get what you want.  It's a bit
hard to know what to suggest without knowing a bit more about the type
of scene you're trying to render.  Perhaps you can give a bit more
detail?  For example, if your spheres are small you might consider
RiPoints instead of a big list of independent spheres.

Cheers,
~Chris

[Aqsis-development] Possibility of Changing Object State Dynamically

[Gabriel <gn...@gm...>]

Hello Chris,

Thanks for the answer :-) Good to know that there is this binary rib 
file :-)

Another concern:

I have seen that there is *RiObjectInstance* which would let me define 
all geometry first and then later apply transformations on these objects 
in  EACH Frame ...
the problem RiObjectInstance only accepts ID's up to 65535,
I need ids up to millions :-) hm...
Is there any way of reusing geometry and transfrom them from each frame 
to another instead of having multiple huge RIB files for each Frame (in 
which all Spheres are defined seperately)

Thanks a lot! :-)

BR Gabriel

On 10/13/2014 03:02 PM, aqs...@li... 
wrote:
> Send Aqsis-development mailing list submissions to
> 	aqs...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/aqsis-development
> or, via email, send a message with subject or body 'help' to
> 	aqs...@li...
>
> You can reach the person managing the list at
> 	aqs...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Aqsis-development digest..."
>
>
> Today's Topics:
>
>     1. Re: Directly accessing the API to render & huge	RAM (Gabriel)
>     2. Re: Directly accessing the API to render & huge	RAM (Chris Foster)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 12 Oct 2014 16:08:01 +0200
> From: Gabriel <gn...@gm...>
> Subject: Re: [Aqsis-development] Directly accessing the API to render
> 	& huge	RAM
> To: aqs...@li...
> Message-ID: <543...@gm...>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Hi Chris,
>
> Thanks a lot for the lovely answer!
>
> Do I understand correctly, as far as I tried, the Aqsis supports gzipped
> .rib files.
> Is that generally a standard? and is there another binary file format
> which uses lower disk space? :-)
>
> another porblem is, Aqsis needs about 16gb ram if I load a RIB file with
> 1 Million spheres (.rib file zipped)  which I would render :-)?
> Can we do better? or does Aqsis reallly need that lot of ram...
> I did not use RiProcedural or any fancy other thing =)
>
> Thanks for the help :)
>
>
> On 10/11/2014 02:02 PM, aqs...@li...
> wrote:
>> Send Aqsis-development mailing list submissions to
>> 	aqs...@li...
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> 	https://lists.sourceforge.net/lists/listinfo/aqsis-development
>> or, via email, send a message with subject or body 'help' to
>> 	aqs...@li...
>>
>> You can reach the person managing the list at
>> 	aqs...@li...
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Aqsis-development digest..."
>>
>>
>> Today's Topics:
>>
>>      1. Re: General Question: Directly accessing the API to render
>>         (Chris Foster)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Fri, 10 Oct 2014 22:24:58 +1000
>> From: Chris Foster <chr...@gm...>
>> Subject: Re: [Aqsis-development] General Question: Directly accessing
>> 	the API to render
>> To: Development related discussion
>> 	<aqs...@li...>
>> Message-ID:
>> 	<CAJ...@ma...>
>> Content-Type: text/plain; charset=UTF-8
>>
>> Hi Gabriel,
>>
>> This is certainly possible - a pretty standard version of the
>> renderman C interface is defined in ri.h which comes with the aqsis
>> distribution.  From there you should be able to get the same
>> functionality as you do via RIB.
>>
>> The standard reference for this kind of thing is the RISpec which is
>> still available from Pixar:
>>
>> http://renderman.pixar.com/products/rispec/rispec_pdf/RISpec3_2.pdf
>>
>> It's nicely written, though as a reference piece it's lacking in
>> complete examples.  In fact, the web as a whole is strangely lacking
>> in full examples of using the C API.  There's a small example
>> available here if you scroll down a bit:
>>
>> http://renderman.pixar.com/view/brief-introduction-to-renderman
>>
>> To a large extent, using the C API is just the same as using RIB, but
>> with C syntax since it's designed to be a very non-chatty interface.
>> Personally I find using RIB to be much more convenient and I'd
>> generally just do so and wear a bit of a disk space hit.  The
>> exception is when creating a lot of procedural geometry on demand, in
>> which case it can be a lot more efficient to use RiProcedural with
>> RiProcDynamicLoad to dynamically generate only the parts of the
>> geometry which are visible.
>>
>> HTH,
>> ~Chris
>>
>> On Fri, Oct 10, 2014 at 5:27 PM, Gabriel <gn...@gm...> wrote:
>>> Hello everybody, :-)
>>>
>>> I am a newbie and I have a short question, hopefully somebody would be as
>>> kind to give me some hints :-)!
>>>
>>> I have tones of objects I want to render: One way would be to first write a
>>> .rib file which could be certainly done and then push that file to Aqsis
>>> render.
>>> The problem is this .rib file is soooo massive (1-10gb) that I dont think
>>> this is the preferred idea.
>>>
>>> Is there a possibility to access the aqsis renderer via a library and then
>>> somehow build the rib objects together in c++ and then call the renderer
>>> with this in the c++ code?
>>> That would be awsome :-).
>>> If that is somehow possible, could somebody please give some hints in the
>>> source code where to find such an interface ?
>>>
>>>
>>> Thanks alot for the help and keep the render spirit alive!!
>>> cool project!
>>>
>>> BR Gabriel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Aqsis-development mailing list
>>> Aqs...@li...
>>> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>>>
>>
>> ------------------------------
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>> http://p.sf.net/sfu/Zoho
>>
>> ------------------------------
>>
>> _______________________________________________
>> Aqsis-development mailing list
>> Aqs...@li...
>> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>>
>>
>> End of Aqsis-development Digest, Vol 79, Issue 2
>> ************************************************
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 13 Oct 2014 00:52:11 +1000
> From: Chris Foster <chr...@gm...>
> Subject: Re: [Aqsis-development] Directly accessing the API to render
> 	& huge	RAM
> To: Development related discussion
> 	<aqs...@li...>
> Message-ID:
> 	<CAJDU5Qk8=yXqPyOgtQD=0ypsxk9s0yGGcfS+PWOhPNMZ=qp...@ma...>
> Content-Type: text/plain; charset=UTF-8
>
> Hi Gabriel,
>
> Aqsis does support gzipped rib.  It doesn't support any other zipped
> formats though you could try writing out binary rib if you wanted.
> IIRC miqser can convert to binary rib so you could try that to see how
> much space you'd save.
>
> About the 16GB - at face value that certainly seems excessive for a
> million spheres, though it depends largely on the details, for example
> * how much of the screen each sphere covers
> * whether the spheres are transparent
> * whether there's any large motion blur or depth of field
>
> Cheers,
> ~Chris
>
> On Mon, Oct 13, 2014 at 12:08 AM, Gabriel <gn...@gm...> wrote:
>> Hi Chris,
>>
>> Thanks a lot for the lovely answer!
>>
>> Do I understand correctly, as far as I tried, the Aqsis supports gzipped
>> .rib files.
>> Is that generally a standard? and is there another binary file format
>> which uses lower disk space? :-)
>>
>> another porblem is, Aqsis needs about 16gb ram if I load a RIB file with
>> 1 Million spheres (.rib file zipped)  which I would render :-)?
>> Can we do better? or does Aqsis reallly need that lot of ram...
>> I did not use RiProcedural or any fancy other thing =)
>>
>> Thanks for the help :)
>>
>>
>> On 10/11/2014 02:02 PM, aqs...@li...
>> wrote:
>>> Send Aqsis-development mailing list submissions to
>>>        aqs...@li...
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>        https://lists.sourceforge.net/lists/listinfo/aqsis-development
>>> or, via email, send a message with subject or body 'help' to
>>>        aqs...@li...
>>>
>>> You can reach the person managing the list at
>>>        aqs...@li...
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of Aqsis-development digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>>      1. Re: General Question: Directly accessing the API to render
>>>         (Chris Foster)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Fri, 10 Oct 2014 22:24:58 +1000
>>> From: Chris Foster <chr...@gm...>
>>> Subject: Re: [Aqsis-development] General Question: Directly accessing
>>>        the API to render
>>> To: Development related discussion
>>>        <aqs...@li...>
>>> Message-ID:
>>>        <CAJ...@ma...>
>>> Content-Type: text/plain; charset=UTF-8
>>>
>>> Hi Gabriel,
>>>
>>> This is certainly possible - a pretty standard version of the
>>> renderman C interface is defined in ri.h which comes with the aqsis
>>> distribution.  From there you should be able to get the same
>>> functionality as you do via RIB.
>>>
>>> The standard reference for this kind of thing is the RISpec which is
>>> still available from Pixar:
>>>
>>> http://renderman.pixar.com/products/rispec/rispec_pdf/RISpec3_2.pdf
>>>
>>> It's nicely written, though as a reference piece it's lacking in
>>> complete examples.  In fact, the web as a whole is strangely lacking
>>> in full examples of using the C API.  There's a small example
>>> available here if you scroll down a bit:
>>>
>>> http://renderman.pixar.com/view/brief-introduction-to-renderman
>>>
>>> To a large extent, using the C API is just the same as using RIB, but
>>> with C syntax since it's designed to be a very non-chatty interface.
>>> Personally I find using RIB to be much more convenient and I'd
>>> generally just do so and wear a bit of a disk space hit.  The
>>> exception is when creating a lot of procedural geometry on demand, in
>>> which case it can be a lot more efficient to use RiProcedural with
>>> RiProcDynamicLoad to dynamically generate only the parts of the
>>> geometry which are visible.
>>>
>>> HTH,
>>> ~Chris
>>>
>>> On Fri, Oct 10, 2014 at 5:27 PM, Gabriel <gn...@gm...> wrote:
>>>> Hello everybody, :-)
>>>>
>>>> I am a newbie and I have a short question, hopefully somebody would be as
>>>> kind to give me some hints :-)!
>>>>
>>>> I have tones of objects I want to render: One way would be to first write a
>>>> .rib file which could be certainly done and then push that file to Aqsis
>>>> render.
>>>> The problem is this .rib file is soooo massive (1-10gb) that I dont think
>>>> this is the preferred idea.
>>>>
>>>> Is there a possibility to access the aqsis renderer via a library and then
>>>> somehow build the rib objects together in c++ and then call the renderer
>>>> with this in the c++ code?
>>>> That would be awsome :-).
>>>> If that is somehow possible, could somebody please give some hints in the
>>>> source code where to find such an interface ?
>>>>
>>>>
>>>> Thanks alot for the help and keep the render spirit alive!!
>>>> cool project!
>>>>
>>>> BR Gabriel
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>>>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>>>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>>>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Aqsis-development mailing list
>>>> Aqs...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>>>>
>>>
>>> ------------------------------
>>>
>>> ------------------------------------------------------------------------------
>>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>> http://p.sf.net/sfu/Zoho
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> Aqsis-development mailing list
>>> Aqs...@li...
>>> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>>>
>>>
>>> End of Aqsis-development Digest, Vol 79, Issue 2
>>> ************************************************
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>> http://p.sf.net/sfu/Zoho
>> _______________________________________________
>> Aqsis-development mailing list
>> Aqs...@li...
>> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>
>
> ------------------------------
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://p.sf.net/sfu/Zoho
>
> ------------------------------
>
> _______________________________________________
> Aqsis-development mailing list
> Aqs...@li...
> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>
>
> End of Aqsis-development Digest, Vol 79, Issue 3
> ************************************************

Re: [Aqsis-development] Directly accessing the API to render & huge RAM

[Chris F. <chr...@gm...>]

Hi Gabriel,

Aqsis does support gzipped rib.  It doesn't support any other zipped
formats though you could try writing out binary rib if you wanted.
IIRC miqser can convert to binary rib so you could try that to see how
much space you'd save.

About the 16GB - at face value that certainly seems excessive for a
million spheres, though it depends largely on the details, for example
* how much of the screen each sphere covers
* whether the spheres are transparent
* whether there's any large motion blur or depth of field

Cheers,
~Chris

On Mon, Oct 13, 2014 at 12:08 AM, Gabriel <gn...@gm...> wrote:
> Hi Chris,
>
> Thanks a lot for the lovely answer!
>
> Do I understand correctly, as far as I tried, the Aqsis supports gzipped
> .rib files.
> Is that generally a standard? and is there another binary file format
> which uses lower disk space? :-)
>
> another porblem is, Aqsis needs about 16gb ram if I load a RIB file with
> 1 Million spheres (.rib file zipped)  which I would render :-)?
> Can we do better? or does Aqsis reallly need that lot of ram...
> I did not use RiProcedural or any fancy other thing =)
>
> Thanks for the help :)
>
>
> On 10/11/2014 02:02 PM, aqs...@li...
> wrote:
>> Send Aqsis-development mailing list submissions to
>>       aqs...@li...
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>       https://lists.sourceforge.net/lists/listinfo/aqsis-development
>> or, via email, send a message with subject or body 'help' to
>>       aqs...@li...
>>
>> You can reach the person managing the list at
>>       aqs...@li...
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Aqsis-development digest..."
>>
>>
>> Today's Topics:
>>
>>     1. Re: General Question: Directly accessing the API to render
>>        (Chris Foster)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Fri, 10 Oct 2014 22:24:58 +1000
>> From: Chris Foster <chr...@gm...>
>> Subject: Re: [Aqsis-development] General Question: Directly accessing
>>       the API to render
>> To: Development related discussion
>>       <aqs...@li...>
>> Message-ID:
>>       <CAJ...@ma...>
>> Content-Type: text/plain; charset=UTF-8
>>
>> Hi Gabriel,
>>
>> This is certainly possible - a pretty standard version of the
>> renderman C interface is defined in ri.h which comes with the aqsis
>> distribution.  From there you should be able to get the same
>> functionality as you do via RIB.
>>
>> The standard reference for this kind of thing is the RISpec which is
>> still available from Pixar:
>>
>> http://renderman.pixar.com/products/rispec/rispec_pdf/RISpec3_2.pdf
>>
>> It's nicely written, though as a reference piece it's lacking in
>> complete examples.  In fact, the web as a whole is strangely lacking
>> in full examples of using the C API.  There's a small example
>> available here if you scroll down a bit:
>>
>> http://renderman.pixar.com/view/brief-introduction-to-renderman
>>
>> To a large extent, using the C API is just the same as using RIB, but
>> with C syntax since it's designed to be a very non-chatty interface.
>> Personally I find using RIB to be much more convenient and I'd
>> generally just do so and wear a bit of a disk space hit.  The
>> exception is when creating a lot of procedural geometry on demand, in
>> which case it can be a lot more efficient to use RiProcedural with
>> RiProcDynamicLoad to dynamically generate only the parts of the
>> geometry which are visible.
>>
>> HTH,
>> ~Chris
>>
>> On Fri, Oct 10, 2014 at 5:27 PM, Gabriel <gn...@gm...> wrote:
>>> Hello everybody, :-)
>>>
>>> I am a newbie and I have a short question, hopefully somebody would be as
>>> kind to give me some hints :-)!
>>>
>>> I have tones of objects I want to render: One way would be to first write a
>>> .rib file which could be certainly done and then push that file to Aqsis
>>> render.
>>> The problem is this .rib file is soooo massive (1-10gb) that I dont think
>>> this is the preferred idea.
>>>
>>> Is there a possibility to access the aqsis renderer via a library and then
>>> somehow build the rib objects together in c++ and then call the renderer
>>> with this in the c++ code?
>>> That would be awsome :-).
>>> If that is somehow possible, could somebody please give some hints in the
>>> source code where to find such an interface ?
>>>
>>>
>>> Thanks alot for the help and keep the render spirit alive!!
>>> cool project!
>>>
>>> BR Gabriel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Aqsis-development mailing list
>>> Aqs...@li...
>>> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>>>
>>
>>
>> ------------------------------
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>> http://p.sf.net/sfu/Zoho
>>
>> ------------------------------
>>
>> _______________________________________________
>> Aqsis-development mailing list
>> Aqs...@li...
>> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>>
>>
>> End of Aqsis-development Digest, Vol 79, Issue 2
>> ************************************************
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Aqsis-development mailing list
> Aqs...@li...
> https://lists.sourceforge.net/lists/listinfo/aqsis-development

Re: [Aqsis-development] Directly accessing the API to render & huge RAM

[Gabriel <gn...@gm...>]

Hi Chris,

Thanks a lot for the lovely answer!

Do I understand correctly, as far as I tried, the Aqsis supports gzipped 
.rib files.
Is that generally a standard? and is there another binary file format 
which uses lower disk space? :-)

another porblem is, Aqsis needs about 16gb ram if I load a RIB file with 
1 Million spheres (.rib file zipped)  which I would render :-)?
Can we do better? or does Aqsis reallly need that lot of ram...
I did not use RiProcedural or any fancy other thing =)

Thanks for the help :)


On 10/11/2014 02:02 PM, aqs...@li... 
wrote:
> Send Aqsis-development mailing list submissions to
> 	aqs...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/aqsis-development
> or, via email, send a message with subject or body 'help' to
> 	aqs...@li...
>
> You can reach the person managing the list at
> 	aqs...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Aqsis-development digest..."
>
>
> Today's Topics:
>
>     1. Re: General Question: Directly accessing the API to render
>        (Chris Foster)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 10 Oct 2014 22:24:58 +1000
> From: Chris Foster <chr...@gm...>
> Subject: Re: [Aqsis-development] General Question: Directly accessing
> 	the API to render
> To: Development related discussion
> 	<aqs...@li...>
> Message-ID:
> 	<CAJ...@ma...>
> Content-Type: text/plain; charset=UTF-8
>
> Hi Gabriel,
>
> This is certainly possible - a pretty standard version of the
> renderman C interface is defined in ri.h which comes with the aqsis
> distribution.  From there you should be able to get the same
> functionality as you do via RIB.
>
> The standard reference for this kind of thing is the RISpec which is
> still available from Pixar:
>
> http://renderman.pixar.com/products/rispec/rispec_pdf/RISpec3_2.pdf
>
> It's nicely written, though as a reference piece it's lacking in
> complete examples.  In fact, the web as a whole is strangely lacking
> in full examples of using the C API.  There's a small example
> available here if you scroll down a bit:
>
> http://renderman.pixar.com/view/brief-introduction-to-renderman
>
> To a large extent, using the C API is just the same as using RIB, but
> with C syntax since it's designed to be a very non-chatty interface.
> Personally I find using RIB to be much more convenient and I'd
> generally just do so and wear a bit of a disk space hit.  The
> exception is when creating a lot of procedural geometry on demand, in
> which case it can be a lot more efficient to use RiProcedural with
> RiProcDynamicLoad to dynamically generate only the parts of the
> geometry which are visible.
>
> HTH,
> ~Chris
>
> On Fri, Oct 10, 2014 at 5:27 PM, Gabriel <gn...@gm...> wrote:
>> Hello everybody, :-)
>>
>> I am a newbie and I have a short question, hopefully somebody would be as
>> kind to give me some hints :-)!
>>
>> I have tones of objects I want to render: One way would be to first write a
>> .rib file which could be certainly done and then push that file to Aqsis
>> render.
>> The problem is this .rib file is soooo massive (1-10gb) that I dont think
>> this is the preferred idea.
>>
>> Is there a possibility to access the aqsis renderer via a library and then
>> somehow build the rib objects together in c++ and then call the renderer
>> with this in the c++ code?
>> That would be awsome :-).
>> If that is somehow possible, could somebody please give some hints in the
>> source code where to find such an interface ?
>>
>>
>> Thanks alot for the help and keep the render spirit alive!!
>> cool project!
>>
>> BR Gabriel
>>
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Aqsis-development mailing list
>> Aqs...@li...
>> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>>
>
>
> ------------------------------
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://p.sf.net/sfu/Zoho
>
> ------------------------------
>
> _______________________________________________
> Aqsis-development mailing list
> Aqs...@li...
> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>
>
> End of Aqsis-development Digest, Vol 79, Issue 2
> ************************************************

Re: [Aqsis-development] General Question: Directly accessing the API to render

[Chris F. <chr...@gm...>]

Hi Gabriel,

This is certainly possible - a pretty standard version of the
renderman C interface is defined in ri.h which comes with the aqsis
distribution.  From there you should be able to get the same
functionality as you do via RIB.

The standard reference for this kind of thing is the RISpec which is
still available from Pixar:

http://renderman.pixar.com/products/rispec/rispec_pdf/RISpec3_2.pdf

It's nicely written, though as a reference piece it's lacking in
complete examples.  In fact, the web as a whole is strangely lacking
in full examples of using the C API.  There's a small example
available here if you scroll down a bit:

http://renderman.pixar.com/view/brief-introduction-to-renderman

To a large extent, using the C API is just the same as using RIB, but
with C syntax since it's designed to be a very non-chatty interface.
Personally I find using RIB to be much more convenient and I'd
generally just do so and wear a bit of a disk space hit.  The
exception is when creating a lot of procedural geometry on demand, in
which case it can be a lot more efficient to use RiProcedural with
RiProcDynamicLoad to dynamically generate only the parts of the
geometry which are visible.

HTH,
~Chris

On Fri, Oct 10, 2014 at 5:27 PM, Gabriel <gn...@gm...> wrote:
> Hello everybody, :-)
>
> I am a newbie and I have a short question, hopefully somebody would be as
> kind to give me some hints :-)!
>
> I have tones of objects I want to render: One way would be to first write a
> .rib file which could be certainly done and then push that file to Aqsis
> render.
> The problem is this .rib file is soooo massive (1-10gb) that I dont think
> this is the preferred idea.
>
> Is there a possibility to access the aqsis renderer via a library and then
> somehow build the rib objects together in c++ and then call the renderer
> with this in the c++ code?
> That would be awsome :-).
> If that is somehow possible, could somebody please give some hints in the
> source code where to find such an interface ?
>
>
> Thanks alot for the help and keep the render spirit alive!!
> cool project!
>
> BR Gabriel
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Aqsis-development mailing list
> Aqs...@li...
> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>

[Aqsis-development] General Question: Directly accessing the API to render

[Gabriel <gn...@gm...>]

*Hello everybody, :-)**
*
I am a newbie and I have a short question, hopefully somebody would be 
as kind to give me some hints :-)!

I have tones of objects I want to render: One way would be to first 
write a .rib file which could be certainly done and then push that file 
to Aqsis render.
The problem is this .rib file is soooo massive (1-10gb) that I dont 
think this is the preferred idea.

Is there a possibility to access the aqsis renderer via a library and 
then somehow build the rib objects together in c++ and then call the 
renderer with this in the c++ code?
That would be awsome :-).
If that is somehow possible, could somebody please give some hints in 
the source code where to find such an interface ?


*Thanks alot for the help and keep the render spirit alive!!**
**cool project!**
**
**BR Gabriel **
*

Re: [Aqsis-development] PointRender Code

[Alistair Leslie-H. <les...@ho...>]

Hi Karsten,

Sounds like you have done some interesting work.  We would be happy to merge your changes. 

The easy way, is to create a Fork of Aqsis (merge you changes into it) and then to a “Merge Request”,  that way people can make comments before it ends up on the main branch.


Best Regards
  Alistair Leslie-Hughes



From: Karsten Daemen 
Sent: Saturday, August 23, 2014 11:03 PM
To: aqs...@li... 
Subject: [Aqsis-development] PointRender Code

Hi All!

During the research I did for my thesis (Non Diffuse Point Based Global Illumination), I made use of the point render code in Aqsis. To be able to use it with my research code, I had to "clean" it up a bit. Do not get me wrong, it was good and performant code (Thats why I used it!), but it was a bit confusing and hacky in some places. 

Anyway, to thank you guys for the great project you delivered, I've prepared a GIT changelist of my changes to the pointrender code of Aqsis. The main functionality remains the same but I made it more object oriented and improved the documentation.

If you would welcome this contribution, please give me the correct permissions and I'll push my changes.

Specific contents of my changelist:

  a.. Extracting code to seperate classes, each with their own header and implementation file. 
  b.. Improved documentation, every function or class is documented with DoxyGen compatible comments. A brief description is given of: The function or Class itself, the possible parameters and the return type. 
  c.. Various TODO points in the code have been fixed, along with some minor bugs. 
Additionally:

  a.. Added detection for OpenMP, it will be included when found on the system. This greatly improves the performance of the pointrender code. (See root CMakeLists.txt, revise this) 
Kind regards,

Karsten Daemen



--------------------------------------------------------------------------------
------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/ 


--------------------------------------------------------------------------------
_______________________________________________
Aqsis-development mailing list
Aqs...@li...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Aqsis-development] PointRender Code

[Karsten D. <kar...@gm...>]

Hi All!

During the research I did for my thesis (Non Diffuse Point Based Global 
Illumination), I made use of the point render code in Aqsis. To be able 
to use it with my research code, I had to "clean" it up a bit. Do not 
get me wrong, it was good and performant code (Thats why I used it!), 
but it was a bit confusing and hacky in some places.

Anyway, to thank you guys for the great project you delivered, I've 
prepared a GIT changelist of my changes to the pointrender code of 
Aqsis. The main functionality remains the same but I made it more object 
oriented and improved the documentation.

If you would welcome this contribution, please give me the correct 
permissions and I'll push my changes.

Specific contents of my changelist:

  * Extracting code to seperate classes, each with their own header and
    implementation file.
  * Improved documentation, every function or class is documented with
    DoxyGen compatible comments. A brief description is given of: The
    function or Class itself, the possible parameters and the return type.
  * Various TODO points in the code have been fixed, along with some
    minor bugs.

Additionally:

  * Added detection for OpenMP, it will be included when found on the
    system. This greatly improves the performance of the pointrender
    code. (See root CMakeLists.txt, revise this)

Kind regards,

Karsten Daemen

Re: [Aqsis-development] Unicode support?

[Ray G. <ra...@da...>]

I've been told by Pixar that Renderman does not support Unicode, and
that it would be a big chore for them to do it, so I'm not holding my 
breath.

Well, if you go with utf-8 interpretation of strings in Aqsis, you'll
be leading PRMan in this area. :)

Ray



On 8/9/2014 1:24 PM, Ray Gardener wrote:
> Does anyone know what Renderman does to support Unicode filenames?
>
>
> On 8/9/2014 4:38 AM, Chris Foster wrote:
>> I don't think this is actually a problem for practical purposes:
>> strings are quote delimited, and when the parser encounters a quote it
>> will scan until the next quote character is found.  The only
>> translation which is done inside a string is for backslash escaped
>> stuff, including the octal escape sequences.  IIRC, UTF-8 uses only
>> non-ascii characters for multibyte encoding, and the minimal
>> processing which does go on when scanning a string is applied only to
>> ascii characters.
>>
>> If there's some reason this doesn't hang together, you could always
>> fall back on the octal escape sequences, but it's messy.
>>
>> On Sat, Aug 9, 2014 at 9:26 PM, Ray Gardener <ra...@da...> wrote:
>>> On second thought (sorry)...
>>>
>>> Direct UTF-8 encoding would violate being able to embed binary RIB
>>> inside a text RIB.
>>> The text format does allow any character to be encoded using
>>> the octal \ddd sequence. So we could format a filespec as a UTF-8 string,
>>> and then encode that using \ddd for any bytes with their high bit set.
>>>
>>> We could also use the binary 0240-0243 command to embed a UTF-8 string.
>>>
>>> If the Aqsis parser already supports the \ddd or the binary commands,
>>> then all that's left
>>> is to interpret the decoded string as UTF-8.
>>>
>>> Ray
>>>
>>>
>>>
>>> On 8/6/2014 5:33 AM, Chris Foster wrote:
>>>> Hi Ray,
>>>>
>>>> No effort has been made to support utf8 in the RIB parser, so I
>>>> suspect it's unlikely to work reliably at the moment.  The RISpec3.2
>>>> says that the encoding is 7 bit ascii, and uses the other 128 values
>>>> for binary encoded RIB.
>>>>
>>>> That said, you should be able to put arbitrary binary characters into
>>>> a quoted string inside a RIB file and these will be parsed literally
>>>> into the internal string representation.  The question then becomes
>>>> whether the underlying system APIs for opening files will accept the
>>>> chunk of binary you've provided.  On linux this may actually work,
>>>> since IIRC the underlying system calls for opening files all accept
>>>> utf8.  Unfortunately, utf8 isn't accepted on windows (utf8 must be
>>>> turned into utf16 wchar_t's before passing to the underlying system
>>>> APIs) and we'd need to sanitize the places where a file is opened to
>>>> fix this.
>>>>
>>>> If someone wanted to tackle this, I'd suggest that we make an effort
>>>> to support utf8 as the RIB encoding, which shouldn't interfere with
>>>> the legacy 7 bit ascii encoding.  IMO there's no point supporting any
>>>> other encodings since (A) RIB is fundamentally a _byte_ stream
>>>> protocol, (B) there's no way in standard-conforming RIB to specify the
>>>> encoding and (C) at this point it's fairly well established that utf8
>>>> is the best way forward in general, with the windows choice of utf16
>>>> being an unfortunate anomaly which can be worked around.
>>>>
>>>> Cheers,
>>>> ~Chris
>>>>
>>>>
>>>> On Wed, Aug 6, 2014 at 9:36 PM, Ray Gardener <ra...@da...> wrote:
>>>>> If I use a filename containing Unicode characters (e.g., in UTF-8
>>>>> encoding in an ANSI Rib file)
>>>>> will that work? There are two situations that come to mind:
>>>>>
>>>>> - Specifying a RIB file to render whose filename contains Unicode
>>>>> characters, most
>>>>>        likely because one or more characters in the parent pathspec do so.
>>>>>
>>>>> - Specifying a Unicode filename to a shader for use as a texture source.
>>>>>
>>>>> In POV-Ray, they have a "global_settings { charset utf8 }" syntax that
>>>>> tells their input parser to interpret subsequent text as UTF-8. Is there
>>>>> anything like that in the Renderman standard, or is it already using UTF-8?
>>>>> Or does the RIB file have to be in 16-bit text format?
>>>>>
>>>>> Ray
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Infragistics Professional
>>>>> Build stunning WinForms apps today!
>>>>> Reboot your WinForms applications with our WinForms controls.
>>>>> Build a bridge from your legacy apps to the future.
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>>>>> _______________________________________________
>>>>> Aqsis-development mailing list
>>>>> Aqs...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>>>> ------------------------------------------------------------------------------
>>>> Infragistics Professional
>>>> Build stunning WinForms apps today!
>>>> Reboot your WinForms applications with our WinForms controls.
>>>> Build a bridge from your legacy apps to the future.
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Aqsis-development mailing list
>>>> Aqs...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>>>>
>>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Aqsis-development mailing list
>>> Aqs...@li...
>>> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Aqsis-development mailing list
>> Aqs...@li...
>> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Aqsis-development mailing list
> Aqs...@li...
> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>

Re: [Aqsis-development] Unicode support?

[Ray G. <ra...@da...>]

Does anyone know what Renderman does to support Unicode filenames?


On 8/9/2014 4:38 AM, Chris Foster wrote:
> I don't think this is actually a problem for practical purposes:
> strings are quote delimited, and when the parser encounters a quote it
> will scan until the next quote character is found.  The only
> translation which is done inside a string is for backslash escaped
> stuff, including the octal escape sequences.  IIRC, UTF-8 uses only
> non-ascii characters for multibyte encoding, and the minimal
> processing which does go on when scanning a string is applied only to
> ascii characters.
>
> If there's some reason this doesn't hang together, you could always
> fall back on the octal escape sequences, but it's messy.
>
> On Sat, Aug 9, 2014 at 9:26 PM, Ray Gardener <ra...@da...> wrote:
>> On second thought (sorry)...
>>
>> Direct UTF-8 encoding would violate being able to embed binary RIB
>> inside a text RIB.
>> The text format does allow any character to be encoded using
>> the octal \ddd sequence. So we could format a filespec as a UTF-8 string,
>> and then encode that using \ddd for any bytes with their high bit set.
>>
>> We could also use the binary 0240-0243 command to embed a UTF-8 string.
>>
>> If the Aqsis parser already supports the \ddd or the binary commands,
>> then all that's left
>> is to interpret the decoded string as UTF-8.
>>
>> Ray
>>
>>
>>
>> On 8/6/2014 5:33 AM, Chris Foster wrote:
>>> Hi Ray,
>>>
>>> No effort has been made to support utf8 in the RIB parser, so I
>>> suspect it's unlikely to work reliably at the moment.  The RISpec3.2
>>> says that the encoding is 7 bit ascii, and uses the other 128 values
>>> for binary encoded RIB.
>>>
>>> That said, you should be able to put arbitrary binary characters into
>>> a quoted string inside a RIB file and these will be parsed literally
>>> into the internal string representation.  The question then becomes
>>> whether the underlying system APIs for opening files will accept the
>>> chunk of binary you've provided.  On linux this may actually work,
>>> since IIRC the underlying system calls for opening files all accept
>>> utf8.  Unfortunately, utf8 isn't accepted on windows (utf8 must be
>>> turned into utf16 wchar_t's before passing to the underlying system
>>> APIs) and we'd need to sanitize the places where a file is opened to
>>> fix this.
>>>
>>> If someone wanted to tackle this, I'd suggest that we make an effort
>>> to support utf8 as the RIB encoding, which shouldn't interfere with
>>> the legacy 7 bit ascii encoding.  IMO there's no point supporting any
>>> other encodings since (A) RIB is fundamentally a _byte_ stream
>>> protocol, (B) there's no way in standard-conforming RIB to specify the
>>> encoding and (C) at this point it's fairly well established that utf8
>>> is the best way forward in general, with the windows choice of utf16
>>> being an unfortunate anomaly which can be worked around.
>>>
>>> Cheers,
>>> ~Chris
>>>
>>>
>>> On Wed, Aug 6, 2014 at 9:36 PM, Ray Gardener <ra...@da...> wrote:
>>>> If I use a filename containing Unicode characters (e.g., in UTF-8
>>>> encoding in an ANSI Rib file)
>>>> will that work? There are two situations that come to mind:
>>>>
>>>> - Specifying a RIB file to render whose filename contains Unicode
>>>> characters, most
>>>>       likely because one or more characters in the parent pathspec do so.
>>>>
>>>> - Specifying a Unicode filename to a shader for use as a texture source.
>>>>
>>>> In POV-Ray, they have a "global_settings { charset utf8 }" syntax that
>>>> tells their input parser to interpret subsequent text as UTF-8. Is there
>>>> anything like that in the Renderman standard, or is it already using UTF-8?
>>>> Or does the RIB file have to be in 16-bit text format?
>>>>
>>>> Ray
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Infragistics Professional
>>>> Build stunning WinForms apps today!
>>>> Reboot your WinForms applications with our WinForms controls.
>>>> Build a bridge from your legacy apps to the future.
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Aqsis-development mailing list
>>>> Aqs...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>>> ------------------------------------------------------------------------------
>>> Infragistics Professional
>>> Build stunning WinForms apps today!
>>> Reboot your WinForms applications with our WinForms controls.
>>> Build a bridge from your legacy apps to the future.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Aqsis-development mailing list
>>> Aqs...@li...
>>> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Aqsis-development mailing list
>> Aqs...@li...
>> https://lists.sourceforge.net/lists/listinfo/aqsis-development
> ------------------------------------------------------------------------------
> _______________________________________________
> Aqsis-development mailing list
> Aqs...@li...
> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>

Re: [Aqsis-development] Unicode support?

[Chris F. <chr...@gm...>]

I don't think this is actually a problem for practical purposes:
strings are quote delimited, and when the parser encounters a quote it
will scan until the next quote character is found.  The only
translation which is done inside a string is for backslash escaped
stuff, including the octal escape sequences.  IIRC, UTF-8 uses only
non-ascii characters for multibyte encoding, and the minimal
processing which does go on when scanning a string is applied only to
ascii characters.

If there's some reason this doesn't hang together, you could always
fall back on the octal escape sequences, but it's messy.

On Sat, Aug 9, 2014 at 9:26 PM, Ray Gardener <ra...@da...> wrote:
> On second thought (sorry)...
>
> Direct UTF-8 encoding would violate being able to embed binary RIB
> inside a text RIB.
> The text format does allow any character to be encoded using
> the octal \ddd sequence. So we could format a filespec as a UTF-8 string,
> and then encode that using \ddd for any bytes with their high bit set.
>
> We could also use the binary 0240-0243 command to embed a UTF-8 string.
>
> If the Aqsis parser already supports the \ddd or the binary commands,
> then all that's left
> is to interpret the decoded string as UTF-8.
>
> Ray
>
>
>
> On 8/6/2014 5:33 AM, Chris Foster wrote:
>> Hi Ray,
>>
>> No effort has been made to support utf8 in the RIB parser, so I
>> suspect it's unlikely to work reliably at the moment.  The RISpec3.2
>> says that the encoding is 7 bit ascii, and uses the other 128 values
>> for binary encoded RIB.
>>
>> That said, you should be able to put arbitrary binary characters into
>> a quoted string inside a RIB file and these will be parsed literally
>> into the internal string representation.  The question then becomes
>> whether the underlying system APIs for opening files will accept the
>> chunk of binary you've provided.  On linux this may actually work,
>> since IIRC the underlying system calls for opening files all accept
>> utf8.  Unfortunately, utf8 isn't accepted on windows (utf8 must be
>> turned into utf16 wchar_t's before passing to the underlying system
>> APIs) and we'd need to sanitize the places where a file is opened to
>> fix this.
>>
>> If someone wanted to tackle this, I'd suggest that we make an effort
>> to support utf8 as the RIB encoding, which shouldn't interfere with
>> the legacy 7 bit ascii encoding.  IMO there's no point supporting any
>> other encodings since (A) RIB is fundamentally a _byte_ stream
>> protocol, (B) there's no way in standard-conforming RIB to specify the
>> encoding and (C) at this point it's fairly well established that utf8
>> is the best way forward in general, with the windows choice of utf16
>> being an unfortunate anomaly which can be worked around.
>>
>> Cheers,
>> ~Chris
>>
>>
>> On Wed, Aug 6, 2014 at 9:36 PM, Ray Gardener <ra...@da...> wrote:
>>> If I use a filename containing Unicode characters (e.g., in UTF-8
>>> encoding in an ANSI Rib file)
>>> will that work? There are two situations that come to mind:
>>>
>>> - Specifying a RIB file to render whose filename contains Unicode
>>> characters, most
>>>      likely because one or more characters in the parent pathspec do so.
>>>
>>> - Specifying a Unicode filename to a shader for use as a texture source.
>>>
>>> In POV-Ray, they have a "global_settings { charset utf8 }" syntax that
>>> tells their input parser to interpret subsequent text as UTF-8. Is there
>>> anything like that in the Renderman standard, or is it already using UTF-8?
>>> Or does the RIB file have to be in 16-bit text format?
>>>
>>> Ray
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Infragistics Professional
>>> Build stunning WinForms apps today!
>>> Reboot your WinForms applications with our WinForms controls.
>>> Build a bridge from your legacy apps to the future.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Aqsis-development mailing list
>>> Aqs...@li...
>>> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>> ------------------------------------------------------------------------------
>> Infragistics Professional
>> Build stunning WinForms apps today!
>> Reboot your WinForms applications with our WinForms controls.
>> Build a bridge from your legacy apps to the future.
>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Aqsis-development mailing list
>> Aqs...@li...
>> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Aqsis-development mailing list
> Aqs...@li...
> https://lists.sourceforge.net/lists/listinfo/aqsis-development

Re: [Aqsis-development] Unicode support?

[Ray G. <ra...@da...>]

On second thought (sorry)...

Direct UTF-8 encoding would violate being able to embed binary RIB 
inside a text RIB.
The text format does allow any character to be encoded using
the octal \ddd sequence. So we could format a filespec as a UTF-8 string,
and then encode that using \ddd for any bytes with their high bit set.

We could also use the binary 0240-0243 command to embed a UTF-8 string.

If the Aqsis parser already supports the \ddd or the binary commands, 
then all that's left
is to interpret the decoded string as UTF-8.

Ray



On 8/6/2014 5:33 AM, Chris Foster wrote:
> Hi Ray,
>
> No effort has been made to support utf8 in the RIB parser, so I
> suspect it's unlikely to work reliably at the moment.  The RISpec3.2
> says that the encoding is 7 bit ascii, and uses the other 128 values
> for binary encoded RIB.
>
> That said, you should be able to put arbitrary binary characters into
> a quoted string inside a RIB file and these will be parsed literally
> into the internal string representation.  The question then becomes
> whether the underlying system APIs for opening files will accept the
> chunk of binary you've provided.  On linux this may actually work,
> since IIRC the underlying system calls for opening files all accept
> utf8.  Unfortunately, utf8 isn't accepted on windows (utf8 must be
> turned into utf16 wchar_t's before passing to the underlying system
> APIs) and we'd need to sanitize the places where a file is opened to
> fix this.
>
> If someone wanted to tackle this, I'd suggest that we make an effort
> to support utf8 as the RIB encoding, which shouldn't interfere with
> the legacy 7 bit ascii encoding.  IMO there's no point supporting any
> other encodings since (A) RIB is fundamentally a _byte_ stream
> protocol, (B) there's no way in standard-conforming RIB to specify the
> encoding and (C) at this point it's fairly well established that utf8
> is the best way forward in general, with the windows choice of utf16
> being an unfortunate anomaly which can be worked around.
>
> Cheers,
> ~Chris
>
>
> On Wed, Aug 6, 2014 at 9:36 PM, Ray Gardener <ra...@da...> wrote:
>> If I use a filename containing Unicode characters (e.g., in UTF-8
>> encoding in an ANSI Rib file)
>> will that work? There are two situations that come to mind:
>>
>> - Specifying a RIB file to render whose filename contains Unicode
>> characters, most
>>      likely because one or more characters in the parent pathspec do so.
>>
>> - Specifying a Unicode filename to a shader for use as a texture source.
>>
>> In POV-Ray, they have a "global_settings { charset utf8 }" syntax that
>> tells their input parser to interpret subsequent text as UTF-8. Is there
>> anything like that in the Renderman standard, or is it already using UTF-8?
>> Or does the RIB file have to be in 16-bit text format?
>>
>> Ray
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Infragistics Professional
>> Build stunning WinForms apps today!
>> Reboot your WinForms applications with our WinForms controls.
>> Build a bridge from your legacy apps to the future.
>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Aqsis-development mailing list
>> Aqs...@li...
>> https://lists.sourceforge.net/lists/listinfo/aqsis-development
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> Aqsis-development mailing list
> Aqs...@li...
> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>
>

Re: [Aqsis-development] Unicode support?

[Chris F. <chr...@gm...>]

On Thu, Aug 7, 2014 at 7:07 AM, Ray Gardener <ra...@da...> wrote:
> Thanks, yeah, implicit utf8 would be compatible and easy.
>
> On Windows the MultiByteToWideChar function can be
> called with the CP_UTF8 flag to convert utf8 to 16-bit.
> Then you just need a central file open function that
> calls _wfopen after doing that conversion.

Right, that's the kind of thing I had in mind.  Aqsis would need a wrapper
around the version of std::ifstream::open() which takes a wchar string,
as documented here

http://msdn.microsoft.com/en-us/library/4dx08bh4.aspx

and possibly also one for creating a C style FILE* as you mentioned.

Regarding wmain() - yep, that's right.  OpenImageIO has the relevant
utility functions already coded up:

https://github.com/OpenImageIO/oiio/blob/master/src/libutil/strutil.cpp#L498
https://github.com/OpenImageIO/oiio/blob/master/src/libutil/filesystem.cpp#L419

Cheers,
~Chris

Re: [Aqsis-development] Unicode support?

[Ray G. <ra...@da...>]

Oh, and on Windows the widechar version of main() should be used
so that it can convert command-line arguments from 16-bit to utf8
before processing.

Ray