Leaderboard

Hi! I want share few V-Ray renderings made about year ago. It is a salad bar concept in to the shopping malls. I can release them now as first bar has built in real life..

SJJ, I have to say that v 9.2.1 has been virtually rock solid for me. I can sympathize with you having problems, but form has been steadily improving in stability. Today is rare that I have any issues with Booleans, unless there's something wrong with the geometry. I would recommend that after running object doctor, you try remodeling any object that has geometry problems. I would also suggest that you use derivatives of your original geometry, that way the geometries match exactly, avoiding any problems at the time you boolean. Now that I think about it, I have run into the disappearing act when performing booleans. Workaround: Try boolean split, not difference. That may do the trick.

Hey All, Here is a prototype project that I am working on. This is actually the 3 iteration (that won't work.). I think I am getting close, however. The other two designs were completely different. ver4 will be based off of this ver3. I get to use 3 of the existing parts (with modifications.). 5 of the 6 parts were produced on a manual knee mill and one part on a manual lathe. the other parts were purchased and modified to accept my parts. Ultimately, it will cut tubing to a prescribed length. (tubing shown in the OGL renderings, but not in the final attempt.) Currently we hand cut them at roughly 120k pieces per year. The device will be controlled by a microcontroller (small computer) that will require me to write the code. The code will be written in Python as well. Which is why I have been so excited for fZ to adopt Python. Even though this will not work as hoped/intended, I did learn a lot about machining and designing something to be so. And, had fun producing it. There is One major design flaw and a few minor ones. Too, there are 2 major execution flaws and a few minor ones (minor ones, I just worked around as I built it.) It is fairly small. In the photos, the grid is 1" There are two adjustable components on the mechanism. One: to adjust the height of the limit switch. This will control the length of cut tube. Yes, I am using stepper motors, where I wouldn't really need to use the limit switch. However, the tubing that I am cutting is kind of slick, so there may be some missed feed steps. Two: to adjust the pressure the feed drive wheel places onto the tube that is, well, fed. This part is hard to see in the images. Both of these adjustable mechanisms are spring loaded to maintain a tension/compression type mechanism to hold its position. I used 3 sizes of screws. 2.5mm for the parts that required them (motors and limit switches.) 3mm for all the fixed holding screws. and 4mm for the adjusting screws. I wanted to only use 2 sizes, but the feed wheel screws needed to be longer than the 3mm options I had. So, I made both adjustments use the same size for future ease of dealing with. It is this project that is inspiring me to write a set of scripts that will figure out all the drill sizes needed. Each screw can use 4 different drill bit sizes. drill to tap, close fit, free fit and head counter bore sizes of drill bits. For those interested in the details about the script, the text is at the bottom. (I don't go into the code, just discuss the details regarding dealing with all the screws). A couple of broken taps and a broken drill bit later, here we are. Version 4 (or 3.2 depending on how we look at it) will be simplified some. Mostly, the adjustable parts will be independent of each other. I Placing the different drill holes manually is pretty tedious.. This version I mostly did it manually. The next version, I hope to have the scripts at least functional. The scripts will use table data for all the screw data, Tap data, and drill bit sizes. These will include both ASME (imperial) and ISO (metric) data. (last image). There are currently 66 metric screws sizes (with Course/Fine threads) data included (this is important for tapping holes) and 56 ASME sizes (including Course, Fine and Extra fine threads). Tables don't have the screw you want? Just add it to the table and the script will be updated. Right now I only have tables for Cap Head Screws, as for the most part, that is what I am interested in using for my projects. Other tables can be made and even the current ones used as templates for new screw types, as much of the data is the same. Biggest difference will be the screw head and it' dimensions. The script should be easy enough to write to accept these other tables. I doubt I will build the tables, as that was days worth of work just for the two I have now. For now, I am not going to build in screw lengths, but will add fields for the user to input this data. This data so far has been a lot harder to gather. All told, I expect there to be around 800 Cap Head screws if you include the shank/thread lengths. I do intend for the script to build the screws for visual intent only. e.g. I am not going to technically build the threads as these should be not visible in projects. And, I think it is a waste of memory. So these scripts will build and deal with visual mockups. Someday, assuming the API will let me, I could have a map placed on for the threads. A drill bit table is also referenced so that in ASAE, the 3 systems of drill bits as well as ISO metric mm sized drill bits will be used. As well as use the closest counterpart across the measurement systems. Currently 680 drill bit sizes are included. from .0135" (.3429mm) to 2" (50.8mm)If you have a drill bit that is not in the table, just add it and the script/s will be able to use it. Too, the script will be able to cross over the two measurement systems without issue. (this project, the parts are built using Imperial tooling as that is what I have, but all the pre-manufactured parts including the Cap Head Screws are metric) In addition, I am going to write a script that will translate objects using the different measurement systems. This won't make up for it being built in, we can hope, but it should aid in dealing with projects that require both. (most of my projects will require both to some degree.) Now the bad news: I think this will take me a while to write, at least to it's completion. There is one issue that I don't see a solution to as of yet. This may take a workaround for the time being. I do hope to have a rudimentary version working soonish. Though, I already know it will require a lot more user input that what I intend to accomplish. Ultimately, I would like to have it hold the data for dimensioning and BOM. Maybe even figure out the screw lengths for us. (((Big if there, as I don't know how to account for all the variables.))) Hope somebody besides me could get use out of something like this. I am going to make it any way, for myself. Cheers! ¢hris (tedious) £und Metric Screw data

Update, I found a way to make this problem go away. When importing the formZ datasmith file into Twinmotion, under options change the Collapse setting to "Keep Hierarchy" instead of "Collapse by Material". This makes the objects "objects" in TM, instead of each material being all the objects it's applied to. I have found it's important to set up good groups in formZ, this makes the outliner in TM more manageable. So, no need for the script, actually, I read some more of the instructions and figured out how it's intended to work.