- Mon Feb 14, 2011 7:48 pm
#337758
If network latency is a problem, then you should first check the value of Options > Check File Version. Check File Version forces a fresh lookup whenever a texture is accessed in the UI, rather than going to the cache. This is for scenarios such as if you were to be commonly using Rhino & PhotoShop at the same time, and you wanted changes you made in PhotoShop to show up in Rhino; of course if things are cached, then you won't see the changes. Also check whether you are using MXM Linking or not; that implies that the plugin is listening for changes to MXM files wherever they may be referenced.
Which preview scene are you using? Do your materials commonly use different ones, so that it's necessary for them to be switched when you switch materials?i have a little issue with rendering the material previews.
they start to update, but at SL1 the image freezes, and then only shows the preview at final SL.
this happens 95% , sometimes it shows the entire process.
my specs:win Xp64 / intel 975x/qx6700/8gb/quadro fx4800 / two screens
Of course, the plugin does cache textures; if it didn't, then it would have to hit your disk every time you saw any kind of a texture thumbnail, anywhere in the UI. The render engine also caches textures, unless you switch preview scenes, which of course implies loading a different MXS and flushing cached data.i work (need to) over the network, hardware is quite decent, server and switch wise, and i get good speeds of ~30-50mb/s when i copy files or save/open documents. But ever since, i see a behaviour with maxwell, that when the software loads textures over the network, the speed is crawling at maybe 5% saturation.
This is really annoying, because IBL files and/or textures sometimes take minutes to load. for material previews that is a real issue and the same goes for FIRE.
If network latency is a problem, then you should first check the value of Options > Check File Version. Check File Version forces a fresh lookup whenever a texture is accessed in the UI, rather than going to the cache. This is for scenarios such as if you were to be commonly using Rhino & PhotoShop at the same time, and you wanted changes you made in PhotoShop to show up in Rhino; of course if things are cached, then you won't see the changes. Also check whether you are using MXM Linking or not; that implies that the plugin is listening for changes to MXM files wherever they may be referenced.
So I don't understand, are you saying this is a plugin problem, or an engine one?also I noticed that three might be another issue than this with using IBL, which is that sometimes even when turning IBL off again the texture is still being loaded to FIRE, but not used in the calculation. I noticed the same when rendering to the network, after turning IBL off again; the dependency was still listed in the monitor console.
As I say, they are, and furthermore, they are cached as good, or as bad, in order to avoid hitting the disk over and over for paths which are known to not exist.in a way, i'd wish textures could be cached ; i think studio does that.
You realize that this defeats the whole purpose of caching textures, right? It is not reading the texture from disk which causes the nastiest hangups, it is asking the OS to tell you if the file exists or not. For huge textures on the local drive caching helps some, but processors are pretty quick these days, so it's not too bad even if they're not cached. The main purpose of caching is to avoid the huge network hit of asking Windows to tell the plugin whether or not a non-local texture exists.a textures list window, like studio would be great too, it could also show if a texture needs update (like a block manager) and show the option to cache it locally.
As I indicated in the last point, this addresses a different problem than the one you are actually trying to avoid. It is nearly as quick to get data over a gigabit ethernet as it is to get it from the local disk. The problem is that none of this matters until you know whether or not the file exists, and by that time, you've already paid the biggest price, whether it does or not.it'd be easy if there was a "force flag" on using the textures in the alternative path. but if double the original location is used. there should be an option "override all found", then an alternative folder could be created locally which the plugIn specifies for rendering locally, but doesn't when rendering out mxs (for network).
Let me take a look at it; I did some work here recently. The inverted proxy image would come into play when you had (a) assigned a Maxwell material with an inverted viewport texture, (b) removed the Maxwell material, and then (c) extracted materials; the Rhino material still has the inverted proxy (Rhino can't invert images in memory, I have to invert the bits and write them to this proxy file to show them in the viewport) path assigned. The solution to that would to use the Remove Materials from Selected Objects and Remove Material from Layer plugin toolbar buttons. When you just delete a material from the plugin's list, it leaves your viewport alone; if there is an inverted (or mxi) proxy image assigned, then it will be left in the Rhino material. If you use those commands though, the plugin removes its material assignement from the object/layer and sets it to use Rhino's 'default' material.the extract & assign material function fails sometimes not assigning the material to the geometry;
and occasionally, but this is an old and rare bug (so i never reported as hard to retrace) i end up with an "inverted proxy image" in a texture but it is not visible in any slot, and i can't get rid off it. it is then hidden in the scene, and even if i replace any texture, it will still be looked for in the dependencies. which is a network killer, as these files are on c:. so i have to dive in there and copy them to a network path, and define it as alternate texture path.
Next Limit Team
- By hwolfejr
- By choo-chee