Kawzy

It's upsetting to see its still an issue. The issue hasn't been replicated for us for some time, whether it was a newer service pack that fixed it or not I don't know. It seems once all of our assets were gradually migrated to max 2013, things are back to normal. It's now rare that we merge in assets that were previously 2012. That seemed to be the most common appearance of the problem. We are now just starting into 2014... I'm sure I'll get to post on some other bug that pops up now. When it was happening, sometimes you could get lucky and it would work if you closed out of Max, open your scene and re-merge. I never found a solid solution, despite a few phone calls to support. I've been using Max for quite some time, and they just kept saying that my scene was probably mapped incorrectly, even after sending archived files of a scene it happened in and one that was working properly to show that I knew how to create a texture. The fact that it was also a problem for a handful of Mental ray users supports that it was on the Autodesk end. I wish I had a solution for you. If you find one, I would be curious as to what it is, but hopefully it phases away for you also.

It should also be said that the process we use, and the only one that has worked consistently well for us, is to "combine by Revit Material" on the Max end when linking. The downside to this is that you'll have to be even more careful as to what objects in Revit have what material applied to them, because objects with the same material will all be one object (i.e. all window mullions, canopies, light fixture etc. that have "proMaterial Aluminum" applied to them will all be selected at the same time). It seems like this is something you may not want at first, because things are all bunched together, but it ends up making things move incredibly fast. You cut way down on selecting and mapping times. As long as I'm working with a Revit guy in our office that models properly and assigns the right material to things, we can import a model and have it "render ready" with limited effort. It allows much more time to create lighting scenarios and model in the details that really make a rendering stand out. This often results in higher quality with much less time. Going the .dwg route and editing what objects are on what layer is a valid route, but if the model changes, you have to spend those hours of conversion all over again. When done right, by linking, all you have to do is click Reload and it updates in Max. You just have to edit your preset, as Jose mentioned. In the Manage Links dialogue, click Presets, highlight "Combine By Revit Material", Modify, and check both boxes under the Materials section. In this window you can also set whether or not you want Max to import Cameras, Lights and Daylight systems, all of which I don't personally have checked. If you have them checked, it will sometimes duplicate lights and systems when reloading and you'll suddenly have a blown out scene. The last thing to consider in this window is how many times you want Max to segment a curved surface on import. Models get MUCH more heavy with higher settings, obviously. It will segment I-beams, countertops, all sorts of things that you don't even care about and your navigation will be sluggish. When exporting an .FBX you can mitigate this a little by also setting the view detail to low. I could go on all day.

No problem, it's what this great forum is for. You'll no doubt run into questions and people on here are often willing to share knowledge. Back in the first stages, there was a lot of correspondence going on with Autodesk around here also, most of which was them not taking the time to even understand the situation. We got a lot of "glitch" comments also. Really it came down to a few of us just diving head first and dedicating a few days to do testing. As crazy as it is to say, it's gotten better. It has it's downfalls, for sure, but it can be a time saver when there are a lot of projects going on at the same time.

We've been working with file linking with Revit and Max since the beginning, and it's been a lot of head scratching and hair pulling. It sounds to me that the problem might lie with what materials are applied to each object/family (forgive my lack of Revit lingo, I'm a Max user and will probably screw up terminology, and also forgive me if you are aware of anything I mention below). The number one thing to get the cleanest imports is to ensure EVERY object has a proMaterial assigned to it in Revit. ProMaterials are the only things that separate properly by material. Using anything else will result in scattered results and materials sometimes being duplicated. Create a material in revit for your glass, or a material for each glass type if you have multiples, and make sure it's diligently applied to only what it corresponds with. It can look like anything, it doesn't matter, but make sure you name it accordingly, because the objects in max will be named the same thing as the Revit material. If you don't break an assembly up into separate promaterials, (promaterial glass on glass, promaterial aluminum on frames) during the conversion Max will combine that assembly. It sees the separate objects of the family as a group. If it can't find something it recognizes to break it apart, it won't. It will be a headache to remedy if it isn't the way you already model in Revit. When we made the decision to move the direction of file linking a few years ago, it was a major process. Some of our Revit team still relapse from time to time, but things go much smoother when a workflow is established. Chances are, adding in file linking through Revit will require a change if you want it to work cleanly. Also, when file linking, you'll possibly find that materials are out of scale when you apply UVW mapping values. Step one when linking a file should be to select all of the linked geometry on the Max end and apply a Reset XForm. This will stay in place if you update the link, and it will allow you to apply correct mapping without having to eyeball it in the viewport. Hope that helps...

@Ernest: I appreciate the criticism, and it's definitely a good point to consider. I hadn't even thought about layering the darker tones. @Jason: Thank you. The sky and overall lighting went through a couple renditions trying to find what added some extra punch and I also thought this worked well.

How many lights do you have in the scene? Just the exterior light? What are your global shadows set to? It almost looks to me as if there is a singular light source and the rest of the scene is being bumped up with an ambient setting, in which case every shadow would be the same value, like your rendering.

Studio/Institution: Architectural Nexus Genre: Commercial Exterior Software: 3ds Max, Vray Description: Hey everyone. It's been a little while since I've been able to post any images, but I'm about to finish up this project and was just hoping for some feedback. Overall I think I'm pretty happy with it, but I always enjoy hearing what others see.

It's been years since we have used it here, so I can't rightly say what is happening. The material isn't getting the same reflective quality for some reason though. You would probably have much better assistance if you moved this post to the finalRender forum. The Cebas users are pretty good at solving things like this.

When opening the asset tracker, the maps in question are not even listed. That was the first thing I checked. Max is just straight dumping them out of the diffuse slot, showing that there was a jpeg file loaded, but not listing what the file was or the path it's possibly trying to find it under. It says nothing more than "jpeg file", and doesn't list them in asset tracker. Even when using the old Bitmap/Photometric paths tool, it shows that no maps are missing. If the file is saved, then re-opened, there are no warnings about maps not being found, there just aren't any maps. We use absolute paths, which I know many are against, but all of our machines pull information from network locations, and all use the exact same roots. The paths are correct. His machine shows them being all pulled from our network location.It isn't a workflow thing... we've worked like this as a team for five+ years.

Latest service pack has been installed. The problem isn't with the linking of paths, but it appears that the problem is entirely random. After merging the model multiple times, it will eventually work the way it should. Then the dice get rolled again as another model is merged. Sometimes, things will work just fine back to back. Sometimes maps will be removed. We may start a local gambling circle, and Autodesk will now be responsible for supplementing a bad habit on top of the hair pulling frustration at times.

I'm not really sure if this is a Vray or a Max issue, but we've just encountered something strange. We've upgraded to 3ds Max 2013, Vray 2.30.01, and there seems to be a problem when you merge an object into a scene. When merging a building a co-worker was texturing, all of the materials that had bitmaps in the diffuse slot misteriously lost their bitmaps. The material is named, the diffuse color comes across, and there is even a bitmap applied to the diffuse channel, but the jpeg map that was once there, located on a network path, is replace with "jpeg file" and no map is present. We've tested this with previous working models, such as cars with maps applied, and it happens with them as well. The only objects that seem to come in with proper materials are proxied objects. Any thoughts?

And to add to that comment, it's also extremely easy to create variations of a tree once you have one you like. All you have to do is click the "random seed" button in Onyx and it takes the parameters you've given onyx for your tree type and randomizes the output. This maintains the qualities you've selected, just creates different configurations as you might find in nature. Of course, the speed at which you can create the tree you want is based on your experience with the program and how closely you want to match the subject. I've had some real buggers that I've had to create, but I'd say start to finish, from modeling the tree and taking it into max to apply textures and make it ready to populate a scene, you're looking at no more than 20-30 minutes. Less if you don't get crazy with the materials and even less if your tree is simple.

I'm far from an expert on video cards and don't know much about them. My video card is actually fairly old, and it's pretty much the only thing that the tech guys keep re-using instead of purchasing a new one because from what I understand it's still a pretty good card. Again, I know little to nothing, and I'm sure there are thousands of users on here that could give you all the info you'd ever need. From what I understand though, the 3450 has a 256 bit memory bus (64x4) and the 9500 has a 128 bit (64x2). Now there's a good chance I'll get laughed at and could be entirely wrong, but that means the 3450 can handle twice the 3d data, making it more efficient. I believe the 3450 also has a larger memory bandwith, which means it can handle larger textures and anti-aliasing better. Again, I wouldn't take that as fact until someone more knowledgable about video cards could add to that, or tell me that I'm way off.

So, I guess in short, I'd probably end up using Onyx just because of the need for certain planting and you can have control over polygon count. Plus if you create a seperate file for each tree and use treestorm, you can quickly generate variations and save them off as proxies to merge into another file. That's how we do it here anyway. Both work nicely however. Sorry I didn't include that in my previous post.

Truthfully, I almost always do exclude them from generating gi. But I just opened the file to double check, and it appears that I was in too much of a hurry and forgot to exclude them. So I guess that's even better for the arguement. I agree xfrog trees look awesome. Unfortunately, they don't have a vast enough library to keep up with our landscape architects, whom I swear choose different foliage every project that we don't yet have in our library just to test us. Because of this, I use onyx a great deal and with opacity mapped leaves, they can look pretty sweet as well. It isn't the BEST rendering of landscape every, but here are some jpegs from the scene and I think they turned out pretty nice. The only xfrog plant is the small, fan leafed ferns along the sidewalk. And I think the rendering was pretty close to 1:30, maybe even 1:45. We have a small farm, but we were having some network issues a few weeks back, so I just rendered it out on my machine to ensure it was done. As far as my macine, it's a fairly new upgrade for me. I believe it's basically as follows i7 920 @2.67 GHz 12 GB Ram Nvidia Quadro FX 3450