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
