No idea really. I’d imagine the first public Mac WIP that has RhinoCycles, but I can’t tell you yet when. I have currently not enough knowledge about the Rhino build system to be able to give a good estimate. In an ideal world it’d all Just Work, but realistically speaking I may have to fix the wrapper code around Cycles.
Cycles itself compiles on the Mac (Blender with Cycles works on the Mac), and I tried to write non-platform specific code. But I may have introduced code that needs mending. I know more when I have worked on the integration for a few days.
Thanks for replying. Having investigated further, it even seems as though the reduced resolution ‘solution’ is not reliable. Not sure why an earlier attempt at reducing the resolution made it start working.
I have also tested several files in preparing a reliable and easy to follow example. A very high resolution photo I took works fine but the attached Google Earth image (from Google Earth Pro), exported and applied as a material to a plane which matches the aspect ratio of the image fails to render no matter what resolution the image is.
You can download the image in question below.
I make a plane that is 4.8m long by 2.383 wide. I have tried applying it directly to the element and via layer. I have tried reducing the resolution substantially. Nothing I can do results in the rendered output rendering the image texture but the image is definitely visible in the viewport.
It seems that the upload process has reduced the resolution down from 4800x2383 to 2399 x 1191. Having now dowloaded the image, it works as a texture. Whatever this website does to images when uploaded, it appears to fix problem.
This is very strange because I have tried taking the image through photoshop and saving as a .png (instead of .jpg)
The whole thing seems very peculiar indeed to me. Can I send you the unaltered original image in some way?
I have just tried again and it still doesn’t work for me when the file is on our server but it does work when saved locally. Some files work fine when saved on our server, others do not. And I have tried saving as alternative formats and different file names.
@pascal could it be that when loading the textures that rhino render gives up if the file takes longer than say, 0.1 second, to fetch and load the file? This could be why larger files generally seem to not work on our server whereas sometimes, smaller ones do work fine.
Clearly Rhino doesn’t have a problem generally with loading files saved on a server. All our .3dm files are saved on the same server and some texture files load fine which is what makes me think it is something size / complexity related.
We regularly work with files which are hundreds of megabytes across many different apps. Also, since first reporting this we have completely changed our network infrastructure and the problem persists.
Hi Robin - I’m at a loss, myself… I tried putting the file on our network and it still renders fine on my dinky little macbook Air from four years ago.
@marlin - do you have an idea what could be going on? Robin’s image shows in a rendered viewport, but if is stored on the network a full render does not show it. Hopefully I’ve stated that correctly - @robinp please correct me if that ain’t it.
Software versions
Rhinoceros version: 5.3.2 (5D197)
IronPython version: not installed
Language: en-GB (MacOS default)
macOS version: Version 10.12.6 (Build 16G29)
Plug-ins
None
Third party kernel extensions
None
Hardware information
Computer hardware
Hardware model: iMac17,1
Processor: Intel Core i5-6500 CPU @ 3.20GHz
Memory: 24 GB
Architecture: Intel 64 bit
Video hardware
Graphics: AMD Radeon R9 M390 2048 MB
Memory: 2048 MB
Screen size: 2560 x 1440, 2560 x 1440
Displays: iMac (217dpi 2x), DELL U2715H (109dpi 1x)
USB devices
asmedia: ASMT1051
GenesysLogic: USB3.0 Hub
Broadcom Corp.: Bluetooth USB Host Controller
Apple Inc.: FaceTime HD Camera (Built-in)
GenesysLogic: USB2.0 Hub
Bluetooth devices
Unknown:
Broadcom: Magic Keyboard
OpenGL information
OpenGL software
OpenGL version: 2.1 ATI-1.51.8
Render version: 2.1
Shading language: 1.20
Maximum texture size: 16384 x 16384
Z-buffer depth: 24 bits
Maximum viewport size: 16384 x 16384
Implementation settings
Use texture compression: No
I was having this issue in Rhino for Mac and discovered a solution. I was pulling the texture from a file on my company’s server (it’s a NAS). I no longer had the issue when I moved the texture onto my computer and linked that file to Rhino instead.