Instead of using XSI's automatic generation, we generate them as needed
for a scene using a script, then we basically rsync them into a cache on
local machines from the render script. This seems to be faster for us
than regenerating them every time, which can take quite a while. Plus
we have more control over how the .maps are generated. I suppose we
could also modify our scripts to have them do the rsync on the original
textures, then regenerate the .map files on the local machines, but I
don't know that this would necessarily be that faster... So, yes, we're
perfectly capable of coding a solution that handles .map files elegantly.
But it's exactly my point that it's possible to work around the issue of
.map files that are generated for the wrong architecture by trashing
them, regenerating them, translating them, and so on. So, the basic
memory-footprint-on-disk functionality of the .map files should ideally
be encapsulated within some sort of data structure and algorithms that
provide a more seamless solution. I'm thinking this behavior should
reside in Mental Ray, so that I can, say, send a scene and a bunch of
.map textures to a renderfarm somewhere and not have to worry about
whether or not they have the same architecture as me. To me, .map files
still seem like a bit of a hack-job. I.e., they work, but haven't been
integrated nicely with the renderer.
Whatever the solution is, it should just work in a production without
help from people like me. And ideally, it should just work with mental
ray standalone as well. As genius as these files are, they're
ultimately just textures to the end user. It shouldn't be complicated
to work with them. Also, header information that is not intrinsically
tied to the data blob on the disk shouldn't live in the file.
- Andy
Halfdan Ingvarsson wrote:
> The thing is, map files should be thought of as completely disposable.
> They're very handy when you have to read the same texture over and
> over again, especially in the tiled version, but a complete dog as any
> form of interchange.
>
> Ideally they should only be generated at the point of render and then
> only on the machine that intends to use it. XSI does provide a system
> for automatically doing that and maybe it should be spelled out more
> clearly in the manual.
>
> - 1/2
>
> ------------------------------------------------------------------------
> *From:* owner-xsi(at)Softimage.COM on behalf of Andy Jones
> *Sent:* Tue 27-Mar-07 18:36
> *To:* XSI(at)Softimage.COM
> *Subject:* Re: 64 vs. 32 bit with map files?
>
> Shouldn't it be possible to encode data about what architecture the file
> was mapped with originally, so that an alternate encoding can be
> generated if there's a mismatch? Clearly, workarounds for this
> problem. It's my opinion that these "workarounds" should be
> incorporated intrinsically into the way Mental Ray (or, failing that,
> XSI) deals with .map files (or some new superior format that replaces
> them). As an example of one such workaround, you could theoretically
> write an "architecture switch" node for the rendertree, then put a bunch
> of differently encoded .maps behind it. That'd be a stupid, clunky way
> to solve the problem, but it would work, unless I'm missing something.
> Right?
>
> - Andy
>
> Luc-Eric Rousseau wrote:
>
> >The goal of .map file to be memory-mapped
> >directly without transformation, so they are by their
> >very nature architecture-specific. They're whole
> >benefit is that they are directly in the memory
> >format. If they were not, then they would not
> >have any benefits over normal file formats.
> >
> >
> >
> >>-----Original Message-----
> >>From: Alan Jones
> >>
> >>ouch - architecture specific image format - who was the
> >>genius behind that idea?
> >>
> >>On 3/27/07, Halfdan Ingvarsson <hingvars(at)softimage.com> wrote:
> >>
> >>
> >>>Yes. Map files are essentially a memory dump of the
> >>>
> >>>
> >>internal image format that mental ray uses.
> >>
> >>
> >>>mr will happily load them from other platforms but doesn't
> >>>
> >>>
> >>make any guarantees about their usefulness in that case.
> >>
> >>
> >
> >---
> >Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
> body:
> >unsubscribe xsi
> >
> >
> >
>
> ---
> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
> unsubscribe xsi
>
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
