Renerabbitt

I did miss that detail but believe it or not we could do this over 10 years ago with a plugin for POVray that no longer exists and it was easy to do but it was from fixed position spherical renderings which looked better than this, it just didnt give you free range of movement, but effectively you were rendering a seen with every color option. it would take 24 hours to render out so I had a second machine doing it but then the options were all html based and switching an option effectively just switched the loaded page through a viewport window but you could still look around, even in VR. I know Epic Unreal engine can currently do this with Epics Product Configurator Template which uses Unreals Variant Manager/Level Varient Sets

I used to offer this and truth be told not all that expensive. Hosted in twinmotion cloud, the end user can walk around the project in twinmotions web based cloud viewer. I'd have to do a bt of work to bring those projects back outside of the archive but it was simpler than you might think. I could probably put together an example in the next few weeks

Ahh okay, that fills in some of the missing context, but I still think there’s one piece I need clarified before I completely accept the SecurityError explanation. I still don’t believe Chief is natively handing you something that is tainted simply because you’re obtaining it at runtime. I’ve been reading external files from Chief at runtime for years without needing to broadly untaint the path, so I still suspect something in the way the directory/path is initially being established in your script is creating the condition. For example, something as basic as this is perfectly capable of reading an external file: path = "C:/Users/rener/Dropbox/DROPBOX PROJECT DIRECTORY/file read.txt" a = open path b = a.read a.close b And I’ve also used systems where I start with a known static root and combine that with information Chief is providing: base_path = "C:/Users/rener/Dropbox/DROPBOX PROJECT DIRECTORY" path = File.join(base_path, $document, "file read.txt") a = open path b = a.read a.close b So runtime evaluation itself isn’t inherently producing the problem. If you post the small initial chunk of code where you obtain the document directory and then hand it to File.mtime, I could probably identify where that security condition is actually being introduced. The other thing I need clarified is what you mean when you say: “The JSON is written into the project folder.” Chief calls these Projects regardless of whether Project Management is turned on or off. The plan/layout still live as a Project in the Project Browser either way. I currently use Project Management and I don’t want to switch it off just to test this, so what I DON’T know is whether Chief has added some functionality in the non-Project-Management workflow that lets you actually bring an arbitrary external file such as a JSON file into the Project Browser itself. If that exists now, that would be new to me. So when you say project folder, do you mean a normal Windows folder outside of Chief, something like: C:/Projects/Smith Residence/ containing: Smith Residence.plan Smith Residence.layout SmartStruc.json and another application is simply writing SmartStruc.json into that Windows folder? Or are you saying the JSON is actually being imported/stored somehow as part of the Chief Project itself through the Project Browser? I’m assuming you mean the first one, but that distinction matters quite a bit in understanding why you’re running into the error. If the JSON is simply an external file on the Windows filesystem, there is no requirement that it physically live beside the Chief plan at all. It can live anywhere on the machine that Chief has permission to read. And that leads into your question about Project Management. Yes, I’ve solved the managed-mode lookup problem You don’t actually need to know where Chief is physically storing the managed .plan. Instead, leave the JSON outside Project Management in a normal filesystem location and use information Chief DOES expose about the current project to locate the corresponding external file. This is actually very similar to a system I used in an older version of Pro Plan. If you still have that version, there was an external CSV-reading system in there that you could probably reverse engineer pretty easily with the additional information I’m giving you here. The basic concept was: static master directory combined with a Chief-derived project-specific directory combined with the known external filename So for example, suppose you maintain projects externally like this: C:/Dropbox/Projects/Main Folder/Folder 1/Example.json You can establish: C:/Dropbox/Projects/ as the known/static root. Then Chief only needs to determine: Main Folder Folder 1 Example from information already associated with the project. You can derive that from Project Information, NVPs, the project name, document name, or whatever naming convention you decide makes sense. So you're not trying to determine: “Where did Project Management physically hide this plan?” You're asking: “Which project am I currently working in?” and then using that identity to resolve an entirely separate external data location that YOU control. I went into this concept in a couple ChiefTalk discussions. This one gets into using project/client information and expanding the available information: https://chieftalk.chiefarchitect.com/topic/45226-designerclient-information-extended/page/2/?tab=comments#comment-337659 And this one gets directly into using a static project root and rebuilding a project-specific path in the Project Management workflow: https://chieftalk.chiefarchitect.com/topic/46157-new-idea-to-export-and-backup-x17-project-files-within-the-project-manager/?tab=comments#comment-329669 That second discussion with Joe Carrick is basically the architecture I’m describing here. Conceptually you can do something like: $dir = "C:/Users/rener/Dropbox/Projects" and then build everything underneath that from Chief’s project information. So if Chief knows: Client = Smith Project = Kitchen Remodel Version = Design A you can resolve something like: C:/Users/rener/Dropbox/Projects/Smith/Kitchen Remodel/Design A/SmartStruc.json without ever knowing or caring where Chief’s managed .plan is physically located. You can make the naming convention whatever you want. For example, you could use: 12345-Smith-Addition and establish a rule that each - represents some directory or subdirectory level. Or you could use separate Project Information values. Or project number + project name. Or client + project + version. There are a bunch of ways to do it. If you post what you would LIKE the external hierarchy to look like, for example: C:/Projects/Smith Residence/Structural/SmartStruc.json and tell me which portions you want Chief to derive automatically, I’m happy to post either the relevant portion of the Ruby or just write the complete lookup for you here. Your JSON would still live outside Project Management just like any other external resource. We’re simply using the Chief project to identify WHICH external JSON should be read. One other option you already have access to I believe you may also have the older Pro Plan version containing my original external CSV lookup system. If you still have that, feel free to reverse engineer the lookup portion. Take this response as explicit permission from me to adapt that particular system for SmartStruc if it helps you get to the final result. The newer BuilderTrend/JobTread implementation in Pro Plan went in a slightly different direction and uses a fully static resolved path. The convenience part is that the user can copy a Windows path and paste it into Chief, and the macro cleans/parses that pasted path into the static address it needs. That implementation is documented here: https://renerabbitt.github.io/ppx18-manual/?chapter=jobtread-buildertrend-spreadsheet-linking So I’ve used both approaches successfully: static root + controlled variable project path and fully static path with automated parsing of a copied Windows address Which one makes more sense really depends on how automated you want SmartStruc to be. Also, why didn’t you like Chief schedules? Now that I know you’re already putting all of this into a dedicated non-model plan, I’m curious what specifically pushed you away from actual Chief schedules. Was it formatting? The inability to create section headings? Control over columns? Something else? The performance issue I mentioned before becomes MUCH less important when the schedules live in a dedicated plan where nobody is actually modeling. If you’re not drawing walls, inserting windows, moving objects, etc. in that plan, you aren’t repeatedly paying the same evaluation cost throughout the normal modeling workflow. And I’ve been able to make actual Chief schedules look very similar to the output you’re generating. I’ll post a screenshot of my Area Analysis as an example. It’s completely schedule based. One obvious advantage your text solution has is that you can insert subsection headings directly into the text output. A single Chief schedule obviously doesn’t give you that same freedom. But you can reproduce essentially the same visual result by splitting the information into multiple schedules and stacking those schedules together. So instead of one schedule with: FOUNDATION ... BEAMS ... HEADERS ... you use multiple smaller schedules, each representing one section, and visually assemble them into the same overall table. That lets you get the headings/divisions while still using actual schedule formatting. It's also way easier to scale into sales and/or additional functions and even calculators derived from a model And if your primary reason for building the custom monospace font was getting the box-drawing characters to align while also matching your drawing set, using actual schedules could potentially eliminate that requirement entirely. That may or may not be useful to you — the custom font approach is clever and obviously already working — but since this is all contained in a dedicated schedule-only plan anyway, I’d be curious what limitation made you abandon the native schedule route. Either way, I think the managed-mode portion is very solvable. And before we completely write off the original SecurityError as Chief simply providing a tainted directory at runtime, post that first little chunk where you establish the directory. I still think there’s a good chance the security condition is being scripted into the lookup somewhere rather than being an unavoidable property of the directory Chief is returning. Also, no way shape or form am i trying to hijack, this thread, if you want me to edit anything out for historical data just lmk, happy to

First off, congrats on even getting this far with it. Building something like SmartStruc and getting Chief talking to an external data source is quite an endeavor. A few things jumped out at me because I’ve spent a pretty ridiculous amount of time working through this exact behavior in Chief. 1. I don’t think the security issue is actually what you think it is The SecurityError is most likely coming from the (assumption) that you’re trying to construct an entirely variable filesystem path. I am guessing because all of the information isn't here, but that's where I would look first. Chief/Ruby will let us read external files, but the path needs to be structured correctly. You can’t simply derive the entire path from variable information and expect it to pass the security parameters. IOW, a completely variable path is something that can potentially be manipulated, which is why it gets flagged. I've actually used two different approaches to this over time. My older external CSV system used a static address combined with a variable system address. Conceptually: static trusted root + variable project-specific portion + known lookup filename That allowed Chief to automatically locate the correct project-specific CSV without making the entire filesystem path variable. That system was live. Chief could continuously parse the CSV and rewrite the cached information as you worked in the plan. The newer BuilderTrend/JobTread system works differently. That system ultimately uses a fully static resolved address. Instead of Chief dynamically constructing the filesystem path every time, the end user can copy the path directly from Windows and paste it into a note. The macro then automatically cuts, cleans and parses that pasted Windows path designation into the properly formatted static address Chief actually uses for the lookup. So there are at least two ways I've already implemented this successfully: static + controlled variable path or fully static path with automated parsing of a copied Windows path Neither requires broadly untainting every filepath. I believe you may actually have a version of my Pro Plan containing the older CSV system, and I believe you also have the current version containing the newer BuilderTrend/JobTread implementation. You can look at the current implementation here: https://renerabbitt.github.io/ppx18-manual/?chapter=jobtread-buildertrend-spreadsheet-linking And take this response as explicit permission from me to reverse engineer/adapt that particular lookup system for SmartStruc if it helps you finish what you're building. Chief also has a Ruby Safe Level setting directly in Preferences. If you completely trust everything being executed through Chief, you could also change that setting and remove some of those restrictions. Personally I’d rather structure the path correctly than globally lower the security level, but the option exists. 2. mtime isn't what makes Chief capable of seeing new data mtime is simply the file's modified timestamp. It can absolutely be used as a trigger. Joe uses it in some of his macros as well. I personally wouldn't consider it ideal as the default mechanism because timestamps can be somewhat volatile, but that's really an architectural decision for you to make depending on exactly what you want this system to do. The important distinction is that Chief does NOT need mtime in order to reread an external file. My earlier CSV implementation proves that. That system was essentially live. Chief would reevaluate the macro during normal plan manipulation, reread the CSV information and continually rewrite the cached information. Draw a wall, move something, place a window, etc. and those calls execute again. So Chief absolutely can continuously reread external data without restarting the Ruby interpreter. In that implementation the amount of information I was producing was relatively small, so the performance penalty wasn't substantial enough to make that architecture a problem. Where I would be more cautious with what you're doing is the word schedule. I don't know from your post whether these are actually Chief schedules generated from notes/objects or whether they're text boxes populated with characters and simply made to LOOK like schedules. Those can be very different performance scenarios. A text box populated by a macro essentially needs to evaluate the macro and display the resulting text. If you're manipulating a note/object that subsequently drives an actual Chief schedule, Chief potentially has considerably more to evaluate because now the parameters of that object are feeding the schedule and that schedule has its own evaluation/rebuild process. I've measured situations in my own development where those evaluations were adding somewhere around 350ms. 350ms isn't particularly meaningful once. It becomes VERY meaningful when drawing a wall, placing a window, moving an object, etc. causes the same evaluation repeatedly throughout normal drafting. So mtime may be perfectly acceptable for what you're building. Or you may decide you don't want the cache rebuilding automatically every time the external file changes. That part is really up to you and depends on exactly what these “schedules” are and how expensive their regeneration actually is. 3. Restarting Chief is one refresh mechanism. It isn't the required refresh mechanism. This is where I think the difference between the systems I've built may help. I've actually used BOTH approaches. My original external CSV system was effectively live. Chief continually reread that external CSV information and rewrote the stored information during normal plan operations. Later, when I built the BuilderTrend/JobTread lookup system, I intentionally chose a different architecture. That lookup is purposely allowed to become stale. Not because Chief requires a restart before it can reread the file. It doesn't. I chose that behavior because this was going into a product being used by end users, and I didn't trust every end user to understand some complicated cache invalidation system or remember which obscure trigger they needed to manipulate. The simplest possible refresh mechanism is: Restart Chief. Everybody understands that. Restarting Chief clears the existing global state and the lookup gets rebuilt when the system initializes again. But restarting Chief is only ONE possible trigger. You could use mtime. You could use an explicit revision value. You could use a timer. You could place an object. You could move an object from one XY coordinate to another. You could change a Project Information field. You could create a dedicated refresh control. There are any number of ways to intentionally cause that data to rebuild. So when you say the parsed data remains stale “until the Ruby interpreter dies on an app restart,” you're describing what your particular cache architecture currently does. You're not describing a limitation of Chief. Chief can continuously reread and rebuild external data. My older CSV system did exactly that. Your scripting decides whether you actually WANT it to. And that's really the important distinction here. There are three different things: Chief reevaluating the macro external data being reread your stored/global cache being rebuilt Those do not have to happen together. You can make all three occur continuously. You can make Chief continuously evaluate while leaving the cache intentionally stale. Or you can create some completely separate deliberate event that invalidates the cache only when you want it refreshed. Your .rb comment is also a separate issue again. If you're bringing the Ruby file in with require, then you've specifically chosen a Ruby mechanism intended to load that code once. That's a code-loading decision. It doesn't establish a requirement that the external DATA itself can only be refreshed by restarting Chief. One other thing I should probably disclose This isn't meant as a brag or some kind of ownership claim. It's just a potentially relevant truth of how I think this very specific information made its way into the AI knowledge you're using. I can't prove model provenance from the outside, obviously, but I'm fairly confident that at least some of the connections being made here originated with work I did developing these systems. And I don't mean that I was “training my AI.” I mean that over roughly the last 3½ years and thousands of hours of scripting, I was feeding the AI systems themselves Chief-specific information they did not otherwise know, correcting their assumptions and showing them how these particular behaviors could be connected. This wasn't broadly documented or open-source information when I started doing it. There were only a few other relevant sources I knew of doing remotely similar things. The important part is that some of what I taught those systems represented earlier iterations of my own development. I hadn't solved every piece yet either at the time that I SHUT DOWN the option to train open source. IOW the current models are still missing some more information that I had solved, especially when it comes to utilizing schedule numbers, which was an expansion on knowledge I gained from Mike and Joe, and the ruby team at chief. So the models can potentially have fragments such as: external file → global lookup → cache information → avoid unnecessary parsing while missing later information about: static + variable path construction → fully static paths parsed automatically from copied Windows addresses → continuous live rereading when appropriate → intentionally stale data when appropriate → performance consequences of repeated schedule evaluation → deliberate cache invalidation when you actually want it That particular combination of correct concepts and missing context is what I'm recognizing in your post. Again, I'm not mentioning that to make some braggart claim to it. It's useful because I know where some of those earlier ideas came from, what problems I subsequently ran into with them and how I eventually worked around those problems. The broader architecture You really have several choices here depending on what you want SmartStruc to do. You can use a static root combined with a controlled variable project-specific address, which is how my older CSV system operated. You can use a completely static resolved path, which is how the newer BuilderTrend/JobTread implementation works, and simply make entering that address easier by automatically parsing a Windows path the user copies and pastes into Chief. Once you've reached the file, you can make the lookup completely live if the performance is acceptable. Chief can continuously reread the external file and rewrite your stored information as the plan changes. I've done that. Or you can cache the parsed information and deliberately allow it to remain stale until some chosen condition tells it to rebuild. I've done that too. Restarting Chief seems easy enough, though I bet if we really were faced with the task of making something better we could do it. It isn't a technical requirement. For your application, I would decide that part based on how expensive those 15 schedules actually are to regenerate and how often the underlying engineering information genuinely needs to refresh while somebody is actively drafting. On #4 I don't have enough information to comment on that one. I'd need considerably more context about how you're constructing the table, what exactly you mean by a schedule here, how the text is being generated, the text box setup and exactly what behavior you're trying to solve before I'd make any assumptions. Happy to help you work through any of this here in the thread if that was part of the intent of the post. I know you're building SmartStruc and I'd genuinely like to see what you do with it. I'm happy to be an audience for it and help where I can. BTW, my big pro tip here is this...if all you're doing with this data is generating schedules, then pull the training wheels off entirely. You don't necessarily need to cache anything at all. Use either the static + variable path method or a fully static path and just let Chief continuously read the external file every time the schedule evaluates. Then create a separate non-model plan whose only purpose is to hold all of these schedules. Nothing gets modeled there, nothing gets drawn there, and you aren't constantly triggering evaluations from drawing walls, placing windows, moving objects, etc. That means the performance hit from continuously reading the external file should be negligible compared to doing the same thing inside an actively modeled plan. So that plan basically becomes a catch-all schedule sheet. Generate all of your schedules there, then send them to Layout through linked views/layout boxes. Now the external data can stay completely live with no cache or stale-state management at all, while the actual working model remains completely unaffected by whatever evaluation cost those schedules have.

The Tray Ceiling tool is effectively creating a set of custom ceiling planes to form the tray. When Recessed is checked, the tool is essentially cutting a hole into the existing ceiling plane and then creating another ceiling plane above it. You can prove this pretty easily yourself. Create a custom ceiling plane in a room with a floor above, cut a hole in that ceiling plane, and then look at the floor structure above. You’ll see that the opening also cuts into the floor structure. That explains why a recessed tray does not work when there is a floor directly above. The program would effectively have to cut a hole through that floor system in order to raise the tray above the room’s existing ceiling height. When Recessed is unchecked, it works differently. The existing ceiling effectively remains intact with no hole cut into it. The tray is then created using additional custom ceiling planes below the elevation of the existing ceiling. Those lower ceiling planes can have the necessary openings in them because they are below the actual ceiling/floor platform and are not cutting into the structure above. So in simple terms, Recessed means the tray is trying to go up through the existing ceiling, while Recessed unchecked means the tray is built downward below the existing ceiling using additional ceiling planes. If you want the appearance of a recessed tray where there is a floor above, define a room on the floor above that matches the size and location of the tray. Then reduce the floor structure thickness in that room by the amount you want the tray recessed. After creating that space within the floor system, generate the tray ceiling with Recessed unchecked. You are essentially creating the recessed space manually in the floor structure above, while letting the Tray Ceiling tool build its custom ceiling planes below the remaining ceiling line without cutting a hole through the floor system.

from what button in what dialog box were you attempting to find the 3d molding? rotating it in the cladding menu is 2d, you likely needed to rotate the original symbol from the library instead, whcih you can do from the cladding menu by selecting it and clicking on the edit button(this is from memory, i am not at my desk right now so the button names may be incorrect)

Distribute this graphic to a team

I guess they don't explicitly state that 3d cladding is just distributed moldings, but yes thats what 3d cladding is.

it needs to be converted to the symbol category of molding, then apply that molding in the cladding dbx

fun fact, the templates I sell are project management based. When you include the number of distributed copies multiplied by the number of revisions, patches and updates, testing, these project files have been effectively installed over 10,000 times. There is no better method for distributing projects than project management... it simply takes less management, less instructions, and less networking. Method is simple, in project management, name your project yymmdd-street/client name-version-technicians initials, such as 260910-Clancy-V1-RR. Done with your work, select your project, hit the delete key, Then this pops up Click Export and Delete Export it to your NAS/Cloud etc. When the next person needs to work on it, they just go to the cloud location and double click it to open it It's a single file that contains all assets. It also can contain additional information and multiple design iterations. There is also no easier way to create a design iteration which includes a layout pre-linked with populated views, but independent from the design it originated from Which results in: Just to reiterate about how to share with a team...you get to press a button(delete key), then click a button(export) to store a single file (with all of its incluuded images assets/pdfs/design iterations/other files) on your favorite cloud service for the next person to work on. The only complicated part about the inter-office sharing part of this, is training people to unlearn the complicated things they were doing before PM was created. If people want to learn about the more complex things you can do in project management, such as creating warehouse detail plans, complicated link swapping, reference file swaps, and pre-loaded linked layout templates etc. PM can do some crazy things, but sharing across a team is not a complicated part of PM, its just .. Delete...click...done.

Right click on the project itself..unless you are not in managed mode

right click and choose delete You should probably export them to keep as a backup

youre using raytrace..the delete surface tool doesnt actually remove surfaces, so the pathtracer is still seeing a surface, and those studs are technically still enclosed by your exterior surface. They are black then because you have no light inside of your stud bays

basically the same method of doing an arched box

Yes, it would, because it would be a unified tool and hotkey