that sounds good... thinking about it now.. it would be great if the adjustments made in the color control box colud be displayed in viewport too. I like that feature, but it is tricky because you only see the changes in the little texture preview window. Here i sometimes struggle to get an image of the whole texture (eg. tiling below 1). A button to view 1:1 pixel could be very helpful.. also for adjusting.JDHill wrote:Thanks for pointing that out polynurb - about eight lines of code changed in strategic places, and we can now (next version, of course) use these textures in the material editor and the Rhino viewport too. Cheers!
Sorry, but that would mean saving a new file to disk, re-building every Rhino material that uses it, and calling a regen on the viewport >> every time you touch a slider. It's already processor-intensive enough (if you didn't notice) to show those changes in the plugin's texture editor.it would be great if the adjustments made in the color control box colud be displayed in viewport too.
It's not your multi-monitor, it happens that way the first time I open it too. Just something in the guts of .NET and Windows, I guess.thanks to my multi monitor system that color control window always pops up first on the primary viewport screen
About all the stuff leading up to that - I highly doubt it has anything at all to do with textures. That message should mean there was something funky with the Rhino render meshes, and Maxwell did not like them. The plugin's Maxwell_CheckFixAndReportBadGeometry command would not be able to detect these kinds of problems - it only knows about them when the attempt to write them into the MXS fails. Check and try adjusting the meshing parameters for the scene. The other clue is that RefreshShade affected this - I am guessing that command re-validates render meshes as it does its' job, so when you exported again after running it, you were exporting different meshes than before you ran it."...export cancled due to meshing errors..."
As with Maxwell, to show textures in the viewport, I just point Rhino at some file on your disk...so you're really asking the wrong guy about this - you need some control in Rhino for how it loads textures. Internally, the plugin reads the file, re-sizes the pixels down to something small, and caches that, so it doesn't have to do a disk-read next time.a tool to control global texture quality, like:
..thought so... but, theoretically could it be done via openGL extension?Sorry, but that would mean saving a new file to disk, re-building every Rhino material that uses it, and calling a regen on the viewport >> every time you touch a slider. It's already processor-intensive enough (if you didn't notice) to show those changes in the plugin's texture editor.
i disabled "restoring viewport materials upon load" so i expected to get the same meshes on reopening;About all the stuff leading up to that - I highly doubt it has anything at all to do with textures. That message should mean there was something funky with the Rhino render meshes, and Maxwell did not like them. The plugin's Maxwell_CheckFixAndReportBadGeometry command would not be able to detect these kinds of problems - it only knows about them when the attempt to write them into the MXS fails. Check and try adjusting the meshing parameters for the scene. The other clue is that RefreshShade affected this - I am guessing that command re-validates render meshes as it does its' job, so when you exported again after running it, you were exporting different meshes than before you ran it.
.. i had a trail copy of AIR render (Sitex) for rhino running for a while.As with Maxwell, to show textures in the viewport, I just point Rhino at some file on your disk...so you're really asking the wrong guy about this - you need some control in Rhino for how it loads textures. Internally, the plugin reads the file, re-sizes the pixels down to something small, and caches that, so it doesn't have to do a disk-read next time.
If you are looking at an object in the Rhino viewport, and it has a texture on it, it does not matter whether it got that way due to the Maxwell plugin, or if you went to Rhino's Object Properties > Material > Texture, and set a path. That's how the plugin does it...you select a texture in the material editor, the plugin creates a Rhino material (same thing you see in obj props > material) and assigns it to the target objects. There is no OpenGL used here, or even possible - Rhino does the OpenGL stuff and renders its' objects using the materials they're given. So the plugin is continuously building new Rhino materials and assigning them in the viewport in order for you to see some working representation of what will be seen in the Maxwell render. Rhino 'owns' the viewport, and gives plugins access to it through the gateway of Rhino materials.
I "saved as", removed all geometry (except three emitters) and now it behaves. ISO and shutter are as they should...If you remove all of the geometry from this scene and just add a simple cube or something, can you still see the error?
Ok. I do know that even with AE off, that if you use MW's "focus" tool.
It alters the f/stop ..
Ah yes, thanks! I had forgotten about that one... haven't used it for a long time. I don't think, however, that AE is the 'problem'...Yes, it figures the fStop to obtain a near/far depth of field which covers specified objects.
But, but... I didn't delete any saved views - only geometry - in the test file. The test-view was named "Cam 01."I suspect that there may have been some funny-business with named views in Philip's file, though I don't really have any way to confirm that.
- By hwolfejr
Any idea of when the Maxwell Sketchup plugin will […]
- By Andreas Hopf
Let's be realistic. What's left of NL is only milk[…]
