|
So, we're in agreement then. Productions need a tool that manages .map
files for them and makes them transparent to the user. The way I see
it, there are two options:
Option 1: Everyone hires me, Alan or some other Jones.
Option 2: XSI and/or Mental Images provides a solution.
As tempting as option 1 is to me in the short term, I'd rather it be
option 2 so that in the long run XSI doesn't get replaced by something
more user-friendly and my expertise beyond .map files is still useful.
- Andy
Halfdan Ingvarsson wrote:
Don't forget problems of endianness, or even non-IEEE754 systems, where your scheme will completely break down. Bear in mind that mental ray works on more than just x86 chips. Also, user-friendliness has never really been their forte ;)
I dealt with it in production way back when and I never thought it much of a problem. I just did the local conversion on the render node and used that to sync up with the server, much like what Andy describes. The map files were never ever used by the artist at any point and neither should they.
You kids today have it too easy :-)
- ½
-----Original Message-----
From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM] On Behalf Of Alan Jones
Sent: 28-Mar-2007 06:05
To: XSI(at)Softimage.COM
Subject: Re: 64 vs. 32 bit with map files?
Halfy and Luc-Eric,
The problem isn't our understanding how it works internally or the reasons why it is so. We're dealing with how to use it in production and while yes it's possible for us to do things to make it work, such a basic feature should work without any user intervention.
I don't see the reason why are format which does work as a memory dump couldn't be made to work on both 32bit and 64bit - 100 megabytes of 32bit floats in a row would be accessed identically on either platform. I'm sure the map file is more complex than that, but it should be possible to make it work.
Cheers,
Alan.
On 3/28/07, Andy Jones <andy(at)thefront.com> wrote:
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
---
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
|
