CPRISM_ status codes in AC12

[Anonymous]

Folks,

Here's a puzzler (at least for me)..

I have a few custom door panels made of butted together CPRISM_ 'planks'. In AC9 sections (which I also used for elevations), the seperate planks were always distinct in the section / elevation views... i.e. you could see the 'cracks' between the planks.

Same objects in AC12 have all the cracks 'healed' (resulting in the door looking like a simple, monolithic panel). I looked in the AC12 GDL manual and see they've changed the status code syntax for prisms. My old parts use the code '15' to show all faces and edges of prisms... even if they are adjoining.

The other annoying consequence of this is that double door assemblies don't show the joint between the two panels at the center of the opening.

Any ideas how to remedy this? I need this info ASAP, as I'm in charge of repairing an AC12 project botched by a sloppy draftsman, and have to get it done quick. Chasing down all these little nuances with the new version is killing me.

Any help would be greatly appreciated!

[Anonymous]

Use a different tool for the second panel (slab_ or extrude).

or,

Script a copy of first panel material, and use it for the second panel.

or,

Create a tiny chamfer (cutform or cutpolya) on both panels.
A shadow will show in rendering. More realistic.
Script it only for a closed door.

[Anonymous]

Olivier,

Hmm.. Yeah, that's what I was afraid of. Going in and hacking the CPRISM_'s into F's did cross my mind, and would look good on the rends (no need to bump map), but the number of polygons it will produce makes me cringe. There's a lot of these planks!

Thanks for the quick reply, brother... I'll go ahead and do the bevel routine and see how it goes. If that doesn't work out well, I'm going to space the planks just a hair, and make a core ply so light can't shine through in a rend.

Thanks again!

BUT... I'd still like a way to display it in 'Classic' style, if it's possible, so if anyone knows how, I'm all ears.... errr... eyes.

[David Maudlin]

Dave:

This problem started a few versions back, I am guessing to make the model generally cleaner (fewer unwanted lines). I solved this by adding LIN_ x1, y1, z1, x2, y2, z2 commands between the door panels when closed, which does not add polygons. I don't know of a simple and elegant solution.

HTH

David

[Anonymous]

The issue of co-planer edges cleaning up with each other
was a "feature" introduced in AC 10. Please see this thread.
http://archicad-talk.graphisoft.com/viewtopic.php?p=96818&highlight=coplaner#96818
As you have apparently jumped from AC 9 to AC 12 you would have
have missed this. As discussed in the above referenced thread,
this behavior is not consistent.
Peter Devlin

[Anonymous]

Guys,

Thanks for all the replies on this.. I went and read the threads Peter pointed to. From 2006!!! Apparently this still has not been solved? This truly sucks!

I'm not tipping all my doors .02 degrees. This completely violates my sense of Universal Order!!

The changes to the PRISM status codes seem to have some significance here.... I'm going to dig into it and see what can be done. I've got to fix this... There's no way I'm adding all that 2D crap to my elevations and sections. I'm a little peeved at all the missing sash lines in the AC12 windows, too. I've already deemed them 'useless' and have reverted back to my old AC9 library parts. I'm bummed out on this, as I really liked some of the other improvements they'd made; especially the ability to assign indoor / outdoor materials independently.

Damn it! This is why I skipped AC10 and AC11. Problems I'd seen noted here and on other forums scared the hell out of me. Now, here I am.. up to my neck in this issue with a deadline looming. Let the games begin!

If I can't find a real fix for this, I'm going to start using FPRISM_'s. I'll have to make my doors bifurcated along the lateral centerline, and live with the resulting huge polygon count. At least I'll get super-duper inside / outside material capabilities with that fix.

It's funny... I've told my kids since they were young, "There's a fine line between a feature and a defect." (not kidding, I'm serious!!)

I guess this is a situation proving that out! At least I get that Moses moment with my kids!

I'll keep you guys posted on developments. I've still got hope for those new status code settings.

[__archiben]

this is not a solution, but might help buy you some time:

what happens if you change the 'line eliminate options' in the plist (registry) file? i must admit to never having tried it, but switching the 'skip GDL elements' option from no to yes (0 to 1) might bring your line back for a wee while, and give you a chance to figure out how to re-code it efficiently?

HTH
~/archiben

[David Collins]

Do your scripts make use of BODY -1 before and after the Cprism_ code?
If so, you might try commenting those out.
I'm not sure what other headaches this might introduce, but it will prevent the coplanar lines from disappearing.

[Anonymous]

Ben & Dave, (sounds like an ice cream or folk group! You guys should team up!!),

Both GREAT ideas... I'm going to try those out and will report back.

Yes, my GDL's do make use of the BODY -1 directive in some cases. Having or not having the BODY directives has never caused any problems in stuff I've written, so I'll give that a shot. Can't hurt.

And Ben... Yeah, I'll take a look at that in the registry. This may be the answer we've all been looking for.

You guys are the best!! Thanks for the ideas on this!!

[Anonymous]

Ben,

You sir, are a genius. You have access to a free home-cooked meal by my dear wife of 20 years if you are ever in the Orange County, CA area.

The registry edit worked like a charm.

AWESOME!!!! Solving this issue was a big deal.

BTW.. I checked my objects that utilize invisible PRISM edges on purpose, and those still function as they should.

Thank You, Thank You, Thank You!!! Did I say Thank You?