Get Blender Image Map To Show Up In Aqsis Render via Mosaic?
Atom
I am revisiting Mosaic/Aqsis pipeline for rendering again and I can't
seem to remember how to get an image map to show up.
I have a properly UV assigned model and the image map shows up fine in
with the Blender Internal renderer, but when I render with Mosaic 0.43
out to Aqsis, I just get a grey model.
Daniel Wray
--
My website:
http://daniel.wray.uk.googlepages.com/
Atom
convert their entire texture map collection to TIFF?
There is code in Blender, open source, that will read most popular
formats. I just don't understand why the developers don't grab the
code and pop it into Aqsis?
On Aug 8, 10:46 am, Daniel Wray <daniel.wray...@googlemail.com> wrote:
> Aqsis only supports TIFF images, you'll need to convert your images to TIFF
> in PS or GIMP :)
>
Daniel Wray
The developers are working very hard on improving Aqsis, if you would like more format support ask them, see what they say.
Chris Foster
>
> Oh yeah, I forgot, one of the reasons I moved on, I mean who wants to
> convert their entire texture map collection to TIFF?
It's really not that difficult, the only possible reason I can see
would be that you don't want to waste disk space. If you've got the
imagemagick image conversion tools, you can convert your *entire*
collection using a bash one-liner on linux, presuming it's all
contained within the same directory structure and it just consists of
png files. It's not difficult to add an extra loop over the possible
image formats you want to convert.
find -name '*.png' | while read fileName ; do convert $fileName
${fileName%.png}.tif ; done
> There is code in Blender, open source, that will read most popular
> formats. I just don't understand why the developers don't grab the
> code and pop it into Aqsis?
Yes, there are libraries such as libpng and libjpeg which we could and
will use eventually (these don't arise from the blender project itself
BTW, but they are open source).
The reasons we haven't done this yet are:
1) The fact that there exist open source tools to do the conversion
very easily and automatically, as I explained above.
2) Our limited time. Our core developer team consists of only two
people at the moment. Even if a feature seems trivial to you, "just
doing it" probably takes a week or two of my "spare" time, and some
features take a heck of a lot more. Of course everyone would like
Aqsis to go faster, have more features, be less buggy etc. We just
can't do everything at once, and in practise we've got to put some
things before others.
The next version after 1.6 is likely to support a large number of
image formats, since I'm thinking of using the up and coming
OpenImageIO library. However, this library didn't exist a year ago
when we started on the work for 1.6. Even if we don't end up using
OpenImageIO we're likely to add support for png and jpg during the
next development cycle.
~Chris.
Chris Foster
> find -name '*.png' | while read fileName ; do convert $fileName
> ${fileName%.png}.tif ; done
Hmm, this should have been on a single line, but gmail "helpfully"
broke the line for me. oops.
animate1978
to use for image maps either. It is a lossy compression format, so
each time that you open it, edit it then save, the image quality
looses data. There will be many artifacts in the image that could be
very obvious in the final render. This is why Jpeg is rarely used as
an image map in the industry, image maps are usually edited dozens of
times throughout the course of a production so each time that one
image is changed, the compression will become more and more obvious
over time.
It is similar to something like mp3, if you convert a CD track to say
96 kbs, then convert the bit rate to 128 you will still hear the same
quality of sound as if it was when you originally ripped it. Also if
you rip it in 320 kbs and then you wanted to add a track to it, then
save it, the lossy compression of mpeg could be noticeable, even at
highest quality. This is because with lossy compression, the more you
save the file the artifacts in the data increases. Basicly these
compression methods throw away data and make an approximation to
counter the loss. This is also why on mp3s you can noticeably hear
certain frequencies that sound "digital".
PNG does not suffer from that kind of data loss as JPEG so if you are
more concerned about disk space this might be something you want to
change. I can agree that TIFF is a large image format, considering
that it can contain some of the highest bits of image data around,
with only HDR formats exceeding that (like OpenEXR or DPX). The image
data it contains the bigger the file. I have a 32 bit TIFF
displacement map that is almost 50 MB in size, so yes just a texture
library alone can be an investment in a new hard drive.
On Aug 9, 5:50 am, Chris Foster <chris...@gmail.com> wrote:
>WHiTeRaBBiT<
I agree that having a wide variety of image formats supported with
Aqsis and Pixie is a just cause, I found it more then a little
confusing why they didn't when I first started with RenderMan. Even
well established commercial renderers such as 3Delight and Air only
support a couple of formats and then not very well (such as Air saying
it supports JPG but not being able to open ones created in a variety
of renderers) :-/ What I later found is that most of the RenderMan
community doesn't care because TIF support more then enough features
for production work and has better universal support between all
programs because its been around so long!
Let me also say that unlike the Blender community where you have
hundreds if not thousands of people and only a few vocal developers
here you have direct access to the developers, which is a good thing
but not if your sarcastic to them. Please be nice, everyone here wants
to help but we have limited resources and we need to stick to things
that really matter (such as fixing bugs and optimizing Aqsis at the
moment, image formats can come later)!!
Eric Back (WHiTeRaBBiT)
Atom
end-user-experience with Aqsis.
The main reason I don't want to convert all my image maps is because I
am using other render systems and I already have other scenes linked
to those image maps in my library. File space is also a concern (as
always). So in a perfect place, yes, I could convert everything, but
in my realistic space, I really don't want to re-link all those other
scenes. I realize TIFF is a Renderman supported image format, but
another reason why I rarely use the format is because there is no
native thumbnail support for TIFF on Windows XP64. So I have no way to
see what my images look like if I place them in the TIFF format other
than opening each one individually in Photoshop.
I really do wish I could help out with the code, but C and C++ is not
my forte. I do quite well with other languages, however.
On Aug 9, 2:07 pm, ">WHiTeRaBBiT<" <whiterab...@dreamscapearts.com>
wrote:
>WHiTeRaBBiT<
formats would help Aqsis stand out in the RenderMan crowd. Maybe if
the developers are interested, and the current round of more critical
bug fixes and release is done, someone will take it on? One potential
headache I can image for the developers though is how well different
formats could actually be supported, I know I've run into real
headaches dealing with compatibility between my current favorite apps
(gimp, cinepaint, inkscape, blender).
Anyway it may also be a good idea to log this in as an official
feature request so they don't forget about it later ;)
http://sourceforge.net/tracker/?group_id=25264&atid=383973
Eric
T G
things just do not make sense or seems even backwards. RenderMan is
it's own beast and quite frankly it is quite a beast to learn let
alone work with. One of the ways to counter a lot of the problems
associated with RenderMan, such as in this case image formats, is that
when constructing a scene to have RenderMan is mind for the final
output. This encompasses ALL areas, from modeling to final render.
This is not limited to Blender either, it is present even in Maya and
Houdini (which have superb RenderMan workflow). Scenes that are built
for Blender simply will need overhaul for RenderMan.
For instance during the development of Project Widow we all have come
across situations where something will work fine in Blender but needs
to be reworked in order for it to render in Aqsis. So you are not
alone when it comes to figuring out the best possible solution. Like
take the case that early on there were several TGA image maps in our
models, however because Blender does not delete that image datablock,
during export and compiling of the textures that TGA file will always
try to be turned into a MIP map which of course cannot be done. While
it doesn't affect performance on the render side, it does take a half
a second longer during export of the Blender scene into RIB. We cannot
delete these datablocks so we are stuck with them forever. Not a big
deal but something that is irritating.
So my suggestion is that in the future when designing a scene for
RenderMan that you can simply choose which maps needs to be converted
into TIFF format, this is what we do. We have a library of textures
that are still in JPEG format but only convert them to TIFF when we
get to them, this saves at least a little space instead of converting
ALL textures. Also on that note we have access to the Animux servers
which provides a substantial amount of disk space, so in your case
just pick and choose. One method that you can try is to have 2
duplicate blend files, one for developing, which you can use JPEGs so
this way you can test and the other for TIFF, just a thought.
Trust me, having more Blender users here that can offer suggestions
and feedback helps all involved, from Eric, to me, to the Aqsis and
Pixie developers, even other developers like Alexei (who made
Shaderman). We are all here to listen and help as much as we can. We
are quite small compared to the Blender users and developers, though
we all do our best to listen and then do what we all can.
Chris Foster
the blender to renderman mailing list archives at
http://groups.google.com/group/blendertorenderman?pli=1 )
On Tue, Aug 11, 2009 at 5:55 AM,
>WHiTeRaBBiT<<white...@dreamscapearts.com> wrote:
> Sounds like valid points to me, also having a wider support for image
> formats would help Aqsis stand out in the RenderMan crowd. Maybe if
> the developers are interested, and the current round of more critical
> bug fixes and release is done, someone will take it on? One potential
> headache I can image for the developers though is how well different
> formats could actually be supported, I know I've run into real
> headaches dealing with compatibility between my current favorite apps
> (gimp, cinepaint, inkscape, blender).
>
> Anyway it may also be a good idea to log this in as an official
> feature request so they don't forget about it later ;)
> http://sourceforge.net/tracker/?group_id=25264&atid=383973
>
> Eric
>
> On Aug 10, 3:37 pm, Atom <atomicpercept...@gmail.com> wrote:
>> I apologize if I come off sounding too crass. I am just offering up my
>> end-user-experience with Aqsis.
>>
>> The main reason I don't want to convert all my image maps is because I
>> am using other render systems and I already have other scenes linked
>> to those image maps in my library. File space is also a concern (as
>> always). So in a perfect place, yes, I could convert everything, but
>> in my realistic space, I really don't want to re-link all those other
>> scenes.
Fair enough, I think this is quite a good reason to want arbitrary texture
support - I can imagine how much of a pain it would be to relink all your
existing scenes, and I presume it's not easily scriptable at all.
Luckily, I've just thought of a way to provide arbitrary texture loading which
might actually be quite easy for us. So easy in fact that I could probably
implement it today :-) How about this:
When a texture file is opened, we first attmpt to open it with the native
image loading interface. At the moment we only support TIFF, OpenEXR, and the
aqsis zfile format natively. If we can open the image, all is well. OTOH,
when the image format is unrecognised, we call through to a user-defined
external application to convert the texture to TIFF.
I think this behaviour should be set to off by default for predictability and
safety. To specify the external converter application, the user should set an
RiOption, something like:
Option "texture" "string converter" "<converter_executable_name> %I %O"
Where %I is the input file name, and %O is the output file name (possibly just
equal to %I with a .tif appended?) If I wanted to use the "convert" program
from the imagemagick tools, I'd just replace <converter_executable_name> with
"convert".
A remaining issue would be whether we just want this to work for
MakeTexture-like interface calls (and in teqser), or whether it should also
work for textures which are referenced by texture() calls in the shading
language. I think that having it work only with MakeTexture would be
sufficient because people shouldn't really be using non-optimized textures in
the texture() function anyway.
Thoughts and opinions please :-) Is this a good idea? How about the
proposed interface - in particular the naming of the "texture" "converter"
option? Note that this is more of a workaround than a permanent fix, but it
may be very useful to tide us over until we have better native image support
for common formats. Furthermore, we're never going to be able to support
every format under the sun, so it will probably remain useful in the future.
~Chris.
>WHiTeRaBBiT<
plain old shell script! Here's one that should work...
#!/bin/bash
#This script intercepts MOSAIC's texture optimizer call to Aqsis's
teqser and autamatically converts input image to a tiff using
imagemagick if necessary.
#NOTE the imagemagick package is required to use this script!!
#In MOSAIC go to "MOSAIC Setttings"->"Render Binary Preset Strings"-
>"Tex Opt" and enter the following: teqser_convert.sh <TEXIN>
<TEXOUT> <WRAP>
input=$1
output=$2
wrap=$3
[[ !("$input" =~ ".tif") ]] && convert $input "convert.tif" &&
input="convert.tif"
teqser -wrap $wrap $input $output
Just copy and save the above text as "teqser_convert.sh' and copy or
link to your global binary folder (such as /usr/local/bin). Then
follow the scripts comments above by entering the script into MOSAIC's
"Tex Opt" binary string for the Aqsis preset. This will create a
CUSTOM preset and save it to the registry. Any texture not a tif will
automatically be converted to a tif before calling teqser. One huge
problem however is this will only work in Linux, not sure how involved
it would be to reproduce this in a dos batch? Another problem with
this approach is some information could be lost depending on what
format is being converted to a tif.
Eric
On Aug 10, 9:35 pm, Chris Foster <chris...@gmail.com> wrote:
> (Cc'd to the aqsis-development list; the rest of this thread may be found on
>WHiTeRaBBiT<
#!/bin/bash
#This script intercepts MOSAIC's texture optimizer call to Aqsis's
#imagemagick if necessary.
#In MOSAIC go to "MOSAIC Setttings"->
#"Tex Opt" and enter the following:
#teqser_convert.sh <TEXIN> <TEXOUT> <WRAP>
input=$1
output=$2
wrap=$3
[[ !("$input" =~ ".tif") ]]\
&& convert $input "convert.tif"\
&& input="convert.tif"
teqser -wrap $wrap $input $output
wrote:
Chris Foster
Good call Eric, this certainly solves the problem for use with Mosaic, and
it's renderer-independent to boot!
I'm wondering where that leaves my original suggestion - certainly I think
your script is better for use with MOSAIC, but maybe there's other
circumstances where my proposal would still make sense? TBH I can't think of
any off the top of my head which would justify the extra complexity in the
aqsis code itself.
~Chris.
Chris Foster
> Hi Chris,
>
> On 11/08/2009, at 11:35 AM, Chris Foster wrote:
>> [...]
>>
>> A remaining issue would be whether we just want this to work for
>> MakeTexture-like interface calls (and in teqser), or whether it
>> should also
>> work for textures which are referenced by texture() calls in the
>> shading
>> language. I think that having it work only with MakeTexture would be
>> sufficient because people shouldn't really be using non-optimized
>> textures in
>> the texture() function anyway.
>
> seem a great idea to me:
> 1. The range of supported images immediately becomes arbitrarily
> large.
> 2. It puts a minimum burden (in terms of functionality) on Aqsis
> itself.
> 3. It will continue to work if native support for an image format
> is implemented, since the converter can then simply be ignored. It
> will therefore be relatively future-proof.
>
> The criticisms of the solution are those that go along with any
> dependency on an external program: we'll have path problems, cases
> where it works on some computers but not others (and Aqsis will take
> the blame for a missing imagemagick install or whatever), external
> programs may do stupid things in the format conversion, etc...
That's why I thought the default would be to have the feature off. The user
could enable it if they knew what they were doing.
> However, I think those are relatively minor issues.
>
> Are you still thinking of using OIIO eventually? It has plugin
> support for a variety of image formats (and, we are told, "more to
> come"):
> http://openimageio.org/wiki/index.php?title=Main_Page
Definitely, I'm on the mailing list for OIIO, and am following the progress
closely. In fact, I'm currently involved in the development in a minor way
(code reviews, design suggestions based on aqsistex experiances, and some
cmake build system code).
> +1 for making it work only for MakeTexture et al... I can see a lot of
> advantages to having some kind of predictability in the images that
> are used while shading.
Cool. What do think about Eric's suggestion (forwarded) though? It seems
like a wrapper around teqser may be a better option.
~Chris.
PS: I'm not sure what the etiquette for posting to multiple lists at once is.
I'm CC'ing all these posts to both lists so that everyone can follow the
conversation. Apologies to the (hopefully few) people who are getting these
posts twice.
>WHiTeRaBBiT<
insert it in MOSAIC with a code fragment then to get a cross platform
script going. Another easy way to do this would be to add that option
as parameters to teqser on the command line, then they could just add
the parameter to the exporters optimizer string (would that be even
easier to code?). I think any approach that works for now is good, but
honestly probably none of these solutions are good enough in the end :-
( The issue is really not image formats but making them more
transparent to the less technically inclined user, otherwise this
issue wouldn't come up (they would just work around it like we already
have).
Eric
On Aug 10, 11:47 pm, Chris Foster <chris...@gmail.com> wrote:
Atom
Adding more bail and wire and more external software to cobble things
together sounds like a bad idea to me. It is just another thing to go
wrong. Then you would still end up with new user posts like this one
(Why doesn't it work?). Also, I don't like the idea of an external
application changing my image on the fly. I would have more confidence
knowing the file I am looking at is actually the file the system is
going to use.
The way I imagine the current code works (remember I have not seen the
actual code) is that you have a section that loads the TIFF or OpenEXR
file into a memory buffer/file/array. That is the key intercept. At
that point in the code, don't give up on a file not found. Fetch the
source code from Blender that already works and can load other formats
and keep trying. Examine the file extension and select the appropriate
function to populate the memory/buffer/file array as needed. I know I
may be stating the obvious.
Is there a guide on building Aqsis on windows?
I have tortoise HG installed, is this compatible with Aqsis?
On Aug 11, 12:54 am, ">WHiTeRaBBiT<" <whiterab...@dreamscapearts.com>
wrote:
renderguy
> At that point in the code, don't give up on a file not found. Fetch the
> source code from Blender that already works and can load other formats
> and keep trying.
engine too? ;-)
Joking aside, it's simply not possible/realistic to do what you're
suggesting from a development stand-point.
It would either be the case of us writing extra plugins for given
filetypes or moving to a library with greater format support (like
OIIO), there's no middle-ground.
> Is there a guide on building Aqsis on windows?
including Windows, on our wiki:
http://wiki.aqsis.org/doc/dev/build
> I have tortoise HG installed, is this compatible with Aqsis?
need either:
* TortoiseGit - http://code.google.com/p/tortoisegit
* msysgit - http://code.google.com/p/msysgit
I use the latter on Windows and seems to work fine, though not as
feature-rich as the Tortoise tools.
Chris Foster
> Adding more bail and wire and more external software to cobble things
> together sounds like a bad idea to me.
All we're trying to do is give you an option which works now, and that
won't take up a lot of our time which is currently being spent on other
things. You're saying we should reuse the work that others have done -
well that's exactly what we're doing here; reusing all the hard work
that people have put into the imagemagick tools.
> The way I imagine the current code works (remember I have not seen the
> actual code) is that you have a section that loads the TIFF or OpenEXR
> file into a memory buffer/file/array. That is the key intercept. At
> that point in the code, don't give up on a file not found. Fetch the
> source code from Blender that already works and can load other formats
> and keep trying. Examine the file extension and select the appropriate
> function to populate the memory/buffer/file array as needed. I know I
> may be stating the obvious.
Yes. As it happens, I wrote the entire aqsis texturing subsystem, so I
think I know how it works.
If you're thinking about implementing a new texture loader:
1) Create a new implementation of IqTexInputFile. CqExrInputFile should
be a nice easy example to follow.
2) Add the appropriate magic number detection to the guessFileType()
function.
3) Instantiate the new loader class inside IqTexInputFile::open()
whenever the appropriate magic number for your favourite format is
detected.
That's all there is to it. If you think that sounds super simple, then
good - I worked quite hard on getting those abstractions right.
As I stated before, I'm thinking of switching to OpenImageIO for image
IO, so that's rather a disincentive for me to implement more image
loader classes - I don't want my effort to go to waste if we just end up
ditching that part of the code in the end. If not for that, I probably
would have at least implemented support for png and jpeg before aqsis-1.6.
> Is there a guide on building Aqsis on windows?
Some sort of instructions can be found here:
http://wiki.aqsis.org/doc/dev/build
I don't use windows personally so can't really help that much.
> I have tortoise HG installed, is this compatible with Aqsis?
Aqsis uses git to host the source code, not mercurical. If you want to
get the code, the appropriate git command is something like
git clone git://aqsis.git.sourceforge.net/gitroot/aqsis
~Chris.
>WHiTeRaBBiT<
These are all just stop gap solutions until the texture library can be
properly done, which do work BTW (I've just seamlessly rendered BBB
content for the first time with that little script :) These kinds of
bail and wire solutions are what make RenderMan and Linux great, you
don't always have to wait on others to get the job done but can pull
it together yourself. In point of fact that's the whole point of
MOSAIC's design, I was able to do point and photon GI the first day
MOSAIC released 2 years ago, long before the support was directly
added (just have to know RenerMan good enough to set it up).
You have to understand in Aqsis there's Paul and Chris actively
coding... that's it, and neither of them are full time! The problem
has been noted and I have no doubts they'll add it in time. Til then
use a workaround solution or build new projects with new tifs and move
on to using/testing other features. I have several bugs/feature
requests myself (some of which are critically important) that I can
either patiently wait for or dig into Aqsis's code and make a
temporary patch, this is how OpenSource works. Unlike a lot of
projects at least your voice has been clearly heard, I would also
still strongly suggest you enter your request in Aqsis's feature
request if you want it remembered later http://sourceforge.net/tracker/?group_id=25264&atid=383973
Eric
On Aug 11, 9:30 am, Chris Foster <chris...@gmail.com> wrote: