Page 1 of 1

Rhino MXS from XP - render on Mac OSX (texture path problem)

Posted: Wed Jun 04, 2008 9:04 am
by bjorn.syse
Hi everyone, I have this problem when using with the following workflow:

1. I model and export an MXS using Rhino 4.0 on Windows.
2. I render this MXS on OSX using a batch script (thus using the command line interface for MXCL)

One of the materials I am using, have textures referenced with a windows path in the material.

These problems occur:

1. First, the problem was a "Connection failed" error, probably resulting from the path beeing something OSX could not connect to.

I tried to solve this, by using the flag -bitmaps: in mxcl, to explicitly point out where to look for bitmaps. This worked, but a new problem occured:

2. The texture placement, I had tweaked in Rhino using "Texture projections" was disregarded, and the textures were placed in a default manner (see the pictures).

Image

Image 1: Correct texture placement (render direct from Rhino/Windows)

Image

Image 2: Default, non-intended texture placement (render using -bitmaps flag on OS X)

So, my question is, am I right using the -bitmaps flag, or is there a better workflow for using Windows and Mac OSX in coalition?

Best regards

- Björn

Posted: Wed Jun 04, 2008 9:39 am
by bjorn.syse
Btw, the same thing occurs on Windows when using the -bitmaps with mxcl.exe

Regards,

- Björn

Posted: Wed Jun 04, 2008 1:43 pm
by JDHill
Hi Björn,

While I wouldn't call this a plugin problem, I tested here with the version I'm running and I can't duplicate this behavior. You might want to move this to the MXCL bugs section to see if other people on 1.6.1 have also seen this.

JD

btw...seeing your example image, you should like this:

Image

This allows per-object rotation for objects using RS-textures. The mapping is rotated using parameters local to the object, so it doesn't change when the object is altered, as happens when using Rhino texture-mappings. The transform is managed internally - it runs on channel zero and does not use any explicit Rhino texture-mapping, so the RS workflow becomes: (a) apply RS material, (b) adjust texture direction in Maxwell Object Properties, (c) do other stuff (i.e. move/rotate/scale/modify) with the object.

Posted: Wed Jun 04, 2008 1:50 pm
by bjorn.syse
That sounds very cool! Textures are a major hassle in Rhino.

How do I move the thread?

Regards,

- Björn

Posted: Wed Jun 04, 2008 1:57 pm
by JDHill
Sorry, move wasn't a good word...I just meant to re-post it there.

Posted: Wed Jun 04, 2008 4:13 pm
by bjorn.syse
Ah, did that. I thought maybe perhaps there was a built in way of moving threads. :)