Jump to content

cgrant3d

Members
  • Posts

    76
  • Joined

  • Last visited

Personal Information

  • Country
    United States

cgrant3d's Achievements

Newbie

Newbie (1/14)

10

Reputation

  1. Use a file history script to keep a history of your Max files. That way if there's a mistake / corruption in the file you can step back to the previous version. Martin Breidt's Incremental Save is a great script for that. It allows you to have YourFileName.max as your working file and all your saves get incremented to 01, 02, 03. But you don't have to worry about what the "current" file is - your current file is always YourFileName.max (no numbers). That means XREF's will work and everything. IMHO the way Max handles incrementing filenames by default is flawed because any other file referencing your file will break. http://scripts.breidt.net/#incrSave
  2. There is no such thing as OEM version of 3ds Max. There are commercial versions and student versions. That's it.
  3. Wow. Those are Lumion native trees right? What is controlling their distribution? Presumably they weren't hand placed...
  4. One more thing. In the past (cs5 I think) I had updated source clips in premiere to a frame shorter and believe it or not that caused premiere to crash when rendering. It's like there was a missing frame that it needed but it didn't gracefully handle - crashed no matter what codec I rendered to. And another - you could try switching premiere to CPU only to make sure it's not GPU related. Good luck - wish I could be there!
  5. Main thing that jumps out at me is that you're reading/writing to the network. Maybe your network is rock solid but that sounds like it could be your problem. I typically source all files from network and write locally but success will be related to network cable/hardware quality too.
  6. Something else that helps when in 32 bit is to not use the VFB because you'd be surprised how much memory it takes with all the render elements. Those of us on 64bit forget about those hundreds of megs / gig+ memory that can easily be taken up by render elements. The basic workflow is for your final image (that you're running out of memory on) save as raw .vrimg file then use the vray command line tool to convert it to an exr w/all elements after the render (outside of Max). The key to reducing the memory footprint with this technique is to set your max resolution to something really small (ie 640x480 or even 64x48, etc) then in the Vray Framebuffer rollout disable "get resolution from max" and enter your final image resolution here. now make sure to enable "render to vray raw" and disable "save separate render channels" ... now when vray renders it will only use enough memory for a 64x48 framebuffer not the full size one you'd normally use (ie 6000x4000, etc).
  7. Just become someone reads the thread doesn't mean they've worked in NY, know the answer to your question or whether they're willing to share something personal like salary... :-) You'll probably have better luck checking salary sites like glassdoor.com ... You probably won't find exactly this field but you could use it as a comparison between locations...
  8. Did you upgrade your BB manager too? BB2012 isn't compatible with 2010 and depending on how you installed 2011 (there was an option to keep IPv4 of IPv6) that could be causing a problem too. We were running all 2010 here until a month or two ago when I migrated everything to 2012. That means the manager / workstations are 2012. Any workstations that haven't received an upgrade to 2012 yet had to have a hotfix applied to their install of BB2010 to allow em to communication with the manager.
  9. You can also xref your materials. It'd take a bit to setup but works well. Only annoying thing is you don't have access to material parameters so you can't verify mat id's, mapping channels, etc except in your master material file. In any case - if you want to go this route I'd make a materials.max file with your materials on a bunch of spheres or something along those lines. Then using xref objects - reference those material spheres into each building file and apply those materials to your building. Note that you can skip the whole xref object step and do them one at a time by creating an "Xref Material" in the material editor but personally I find the xref object process more intuitive.
  10. I have to admit I'm amazed and enthralled at the possibilities! However - there *has* to be a weakness to this technology (ie animation, reflection, refraction, transparency).
  11. I tracked down the problem - the plugin VRayScatter from rendering.ru ... Presumably it's not nitrous optimized or something along those lines. In 2010 my shaded playback w/VRS was 37s and w/o was 32s - not a huge deal one way or another. However in 2012 shaded playback w/VRS was 180s and w/o was 16s! Crazy. So to set the record straight on this project I'm seeing a 2X improvement (in 2012 nitrous) in shaded but only half speed in wire - I'll see if changing drivers can improve the situation... The unusual thing is speed wasn't affected by hiding VRS - it was still dragging the performance down. I had to disable the emitters or remove in order to see reasonable performance. Also worth mentioning that MultiScatter (which is the current MR/VR scatter tool as opposed to the older VRS) does *not* suffer the same performance problem in 2012.
  12. Haha - yeah we skipped 2011 entirely. Used it a few times but found it to be slower and clunkier for everything we do. I had hoped moving to 2012 we'd see some significant improvements - especially since nitrous is multithreaded. Actually speaking of threading - are there still problems 6 core machines? I thought that'd been worked out but the new workstations ore Dual 6-core Xeons w/hyperthreading.
  13. Oops - was in a bit of a hurry to post and so didn't clarify the important details... I meant to say I disabled "real time" playback in the "time configuration" dialog - not "viewport config"... The reason being things felt "slow" in 2012 so I wanted a measurable, consistent comparison. So by animating a camera in a production scene I was reproducing what we'd actually experience in a standard project. Disabling "real time" ensured no viewport degradation would come into play that'd skew the results... Oh and I shouldn't have even bothered mentioning it was from Revit. We use VRay so none of the materials are ProMats/Autodesk mats (personally I can't stand either - even if I was to use MR I'd dump those). I even did a test where I applied a Standard mat to everythign (just in case it was a VRay shader problem) but it didn't affect the time much at all... FYI - I edited the original post to include the time in 2012 for "realistic" as well.
  14. Presumably there are quite a few of you using 2012 in production by now. I'd like to move to 2012 for production but from what I'm seeing in real-world files the performance difference is dramatically *slower* in 2012. I opened a file that originated in Revit (though everything has VRay mats), has 2200 objects, 380K poly's & 33 materials. Not huge by any means... It's all static geometry with default lighting - only thing animated is the camera... However here are the frame times I'm getting when I disable "realtime" in the viewport config and play through an animated camera. 2010 shaded: 37s wire: 13s 2012 (nitrous) realistic: 190s shaded: 180s wire: 178s That's roughly 5X slower in shaded mode and 13X slower in wireframe. Good grief. Obviously this can't be what everybody sees because all I ever hear about 2012 is how fast nitrous is. Thoughts? System is a freshly ordered Dell Precision T7500, 20GB, Quadro 4000 & Win7. ... [EDIT] Resolution found - issue was VRayScatter dramatically reducing viewport performance in 2012. http://forums.cgarchitect.com/67046-2012-wheres-nitrous-speed.html#post336604
  15. Hey Dave - one of my favorite scripts is VMC (VRay Material Control) that lets you set virtually any material property en masse. It's trivial to do the first 2 with it: http://www.scriptspot.com/3ds-max/scripts/vmc-vray-material-control I briefly check the VRay Light Lister script and it doesn't seem to reveal the "affect specular" option so that'll take a bit of custom code. You can sloppy select a bunch of lights / geometry that you want to affect (even a select all will work), paste this text in the maxscript listener and hit the numeric enter key to run it. That'll turn off affect specular on all VRay lights within the current selection. for l in selection where classof l == VRayLight do try (l.affect_specular = off) catch()
×
×
  • Create New...