[Josephus Holt]

JD, I'm modeling a large custom home and site in Rhino but as I've added Onyxtrees I'm finding that the export to Maxwell takes forever, so I exported all to C4D in order to render out to Maxwell from C4D. All is working well in x32 but crashes immediately as I hit the render button....same problem as before, but different scene.

So far the scene file is small enough (about 20% of Rhino file size) so working in 32 bit should not be a problem, but was wondering if you ever had a chance to look further into this issue.

[JDHill]

Just let me dig out the old email and see how that works...

[JDHill]

As I recall, the original issue was occurring on Cinema x64, correct? I tested your Oliveri kitchen again, since I'm back on x64 now, and it works fine here, either in Cinema x86 or x64. I then exported that Wolf range you sent me from Rhino as an .obj (tried a couple of different .dxf exports and nothing useful was coming into Cinema, so I just used .obj) and tried rendering that from Cinema, and no problems are showing up there either.

Could you describe at all what happens when it crashes, meaning, what sort of dialog is shown (assuming one is shown)?

[Josephus Holt]

yes, only in x64. This is a completely different scene BUT has a combo of dxf and obj imports from Rhino.

When I hit "render" (to Maxwell) Rhino quit...I think it said something like "Rhino can not continue...".

I'm running a bunch of renders at the moment, but in the morning I'll try an OBJ (only) export and see what happens. I prefer the dxf export as it brings in all the layers....Stefan Laub (VRayforC4D) said that they "all" do it that way there (in Austria:)...model in Rhino, export via dxf to C4D and render either to Maxwell or VRay.

[JDHill]

To be clear, I was not suggesting you switch to .obj. If there is possibly something related to .dxf import which is causing errors, and which I can detect, then by all means, I will do so. I'll give a few more tries at using different .dxf-export options from Rhino and see if I can get that range to import...

[Josephus Holt]

I know you were not suggesting that...you're always one to try all you can for a solution first.

I used the default translator but changed the setting for polysurfaces to be exported as meshes.

Chickamauga....not a place too many know about....although he would like to have, Braxton could not Bragg about the outcome there

EDIT: ran a few quick tests:
Rhino DXF export to C4D (some geometry did not come over), no problems with C4D 32bit, but crashed C4D 64bit as soon as I hit the Maxwell "render" button (see screenshot).



Rhino OBJ export to C4D: no problems with either C4D 32bit or 64bit, so will use the Rhino OBJ exporter for now...the files are quite a bit smaller than the DXF files so that helps too. May be another story when it comes to applying materials and getting the right texture map scale and orientations.

[JDHill]

Thanks, I got hung up on some other issues, and so have not checked the .dxf issue out yet. I'll let you know what I find. In the meantime, I would be curious what would happen, using the .dxf import that crashes, if you went into the Scene Object and enabled Output > Disable materials. Part of what I was debugging that got me sidetracked from this was related to some bad texture files (not bad, but crashing the image-reading library used by the plugin) which came in from some xfrog trees. You're using onyx, but it's something to check anyway, since there aren't any other good indicators showing up yet.

[Josephus Holt]

Scene Object and enabled Output > Disable materials.

tried it, still crashes.

Although the DXF export from Rhino to C4D (likely 32 bit) was highly recommended, at this point I don't see any reason NOT to use OBJ as it seems to be doing a better job. I'm sure you've got more pressing issues to work on, so I'm not sure at this point if I need a "fix" on the dxf to c4dx64 issue.

[lllab]

it is the tress, ia m quite sure. not the format.
i have the same problem. also when i deactivate materials. only when i delete the trees from scene it renders ok.
try deleting the trees from scene, and also its materials from material manager. see if it still crashes. as JD said there seem to be some kind of textures that make problems.

dxf is certainly the best method from rhino to c4d. we use this since years, it renders fine, also with maxwell,. and keeps a good OM structure and the base material colors.
i tested the crashes with geometry from many format inputs obj makes no difference., it was nailed to the trees in my case from xfrog (those are native c4d format no dxf)

maybe check if you have also a uvw map somewhere with no texture on it. i am not sure yes if that makes some probs, but maybe try.

cheers
stefan

[Josephus Holt]

it is the tress, ia m quite sure. not the format.
i have the same problem. also when i deactivate materials. only when i delete the trees from scene it renders ok.
try deleting the trees from scene, and also its materials from material manager. see if it still crashes. as JD said there seem to be some kind of textures that make problems.

dxf is certainly the best method from rhino to c4d. we use this since years, it renders fine, also with maxwell,. and keeps a good OM structure and the base material colors.
i tested the crashes with geometry from many format inputs obj makes no difference., it was nailed to the trees in my case from xfrog (those are native c4d format no dxf)

maybe check if you have also a uvw map somewhere with no texture on it. i am not sure yes if that makes some probs, but maybe try.

cheers
stefan

Greetings Stefan, nice to hear from you here Just to clarify, I have no problems exporting the mxs file out of C4D-x32, but the same scene crashes C4D-x64 when exporting the mxs. It seems to make no difference whether it is DXF or OBJ from Rhino to C4D (what is "OM Structure"?).

I turned off (for export) all layers except the house and c4d-x64 crashes on export to mxs. When I isolated the object (layer out of Rhino) that was crashing, I found that I could export to mxs that object alone ok but when combined with the other layers of the house it crashed when exporting mxs file in c4d-x64. The trees, as you say, are also crashing x64, but as I said all is well in x32

I did go ahead and assign a generic Maxwell material to each object just in case that was the problem, which it did not seem to affect it one way or another.

Perhaps I'm getting exasperated over nothing, as at least Maxwell x64 has access to as much ram as it needs....just feel like it won't be long and I'll need that ram in c4d as well....especially since I'm getting rather fond of the 3D Onyxtrees

I suppose that exporting the mxs out of Rhino is more of an option now that v5 has an x64 version. I've noticed though that the c4d scene file is quite a bit smaller than the Rhino file, so makes exporting faster. Also my 3DSpaceNavigator/graphics card can't handle all the 3d trees in Rhino, although I can leave that layer turned off while navigating and then turning them on when I've got the right view...is a little more tedious than c4d (I'm quite fond of the way c4d does a lot of things as far as the overall scene is concerned...although Rhino can't be beat IMO for modeling).

[JDHill]

Not that it's any kind of solution to the real question, but are you using the cinema plugin's instance object at all? If you have one tree that you need multiple copies of, and that particular one is not crashing cinema, then making instances of it should also pose no problem. So, what I'm saying is that on x86, using instances would help you with memory, while on x64, it may help with this crashing problem. The instance object is pretty robust - you can create a copy of a whole tree of objects, or even instance other instances...just make sure that you don't end up with intersecting instanced items, because this slows down the render.

[Josephus Holt]

Not that it's any kind of solution to the real question, but are you using the cinema plugin's instance object at all? If you have one tree that you need multiple copies of, and that particular one is not crashing cinema, then making instances of it should also pose no problem. So, what I'm saying is that on x86, using instances would help you with memory, while on x64, it may help with this crashing problem. The instance object is pretty robust - you can create a copy of a whole tree of objects, or even instance other instances...just make sure that you don't end up with intersecting instanced items, because this slows down the render.

No, I've not used instances yet as I've seen some posts on the forum here that seem to discourage the use of them. With trees I would have to be REALLY careful that they don't intersect other instanced-trees, but is doable. That would definitely get me around the x32 ram limit as c4d is much lighter with the file size than Rhino.

What may make life a lot simpler is to stay inside Rhino and use the Worksessions command with attached file(s) and use instances whereever possible. I'm still very new to Rhino (using it for less than 6 mos), and still learning it...GREAT program! This way I can avoid having to go through C4D...especially now that Rhino 5.0 has a x64 version.

By the way...so far no crashing with Rhino when using the 3DOnyxtrees.

[lllab]

ok sorry to have missunderstood you.

cheers
stefan

[Josephus Holt]

JD....looks like I'm at the point of having to use x64...were you able to get a "fix" on the angle limit setting that is crashing my file? It's a bit of work everytime to select every tag and deselect angle limit.

By the way...so far ( x64 not crashing as long as I do the above.

Joe

[JDHill]

Your scene is the only one I've been able to duplicate this with so far, but Stefan is going to send me some smaller files he has that are also affected, to make it easier to try to chase down the root cause (your file pretty much maxes out the memory on my machine). So hopefully I'll know more about this later, but for now it looks like there is something 'wrong' with the tags, at least from the perspective of them not getting along with however the Maxwell SDK digests the geometry I give it.

It also looks like the operative thing is to force Cinema to recalculate things, and that might mean either disabling/re-enabling those tags, or, as Stefan also found, changing their angle value. I'm not 100% on that part though until I can try it for myself, and it doesn't alleviate any more work from the perspective of having to select them all anyway.

With that in mind, here's a script you can use to quickly enable or disable all the phong tags in a document:

Code: Select all

enablePhong(obj, enabled)
{
   while(obj)
   {
      var ptag = obj->GetFirstTag();

      for (ptag; ptag; ptag = ptag->GetNext())
         if (ptag->GetType() == Tphong)
            ptag#1001 = enabled;

      enablePhong(obj->GetDown(), enabled);
      obj = obj->GetNext();
   }
}

main(doc, op)
{
   var obj = doc->GetFirstObject();

   if (!obj)
   {
	    TextDialog("There are no objects.", DLG_OK);
   }
   else
   {
      var result = TextDialog(
         "Enable Phong tags? \r\n (Yes = enable, No = disable)", 
         DLG_YESNOCANCEL + DLG_ICONQUESTION);

      if (result != DLG_R_CANCEL)
			   enablePhong(obj, result == DLG_R_YES);
   } 
}

Just go to Window > Script Manager, delete whatever's in the 'Menu State' textbox, replace whatever is in the in the main textbox (where the code is) with the above, change the 'Name' to something recognizable like 'EnableOrDisablePhongTags', and click Save All. After doing so, you should have a new 'EnableOrDisablePhongTags' item in Plugins > User Scripts.