Jump to content
AutoDesSys Forums


Popular Content

Showing content with the highest reputation since 04/20/2022 in Posts

  1. 5 points
    ¢hris £und

    fZ vs a Real build.

    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
  2. 4 points

    Example Images

    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..
  3. 2 points

    background saving of files

    it would be so great if you could implement background saving of files! when working on large projects, it's generally good to save automatic backups from time to time. but if the saving starts during a complex modeling task, it will interrupt the workflow for a few seconds and even longer - if you set corresponding save options before. as an example, if you set FZ to save your project automatically every 5 minutes, this easily ist starting to develop into a serious workflow stopper.
  4. 1 point

    Example Images

    Really nice Jaako....Quality work!
  5. 1 point

    Unreal 5

    Hi all, Since Unreal 5 was just released, and I had really already become a Twinmotion convert, I have chosen to dive directly into Unreal 5. With the new Lumen feature there is no light baking anymore, you see everything with GI and so forth. I have found the way to make at least a point to point camera animation and render it out, so I have tried some things. There is a "living city" thing that is just awesome that comes as a free example project. There is a lot of trash in it, (it seems it's trash day) but it's as easy as clicking a trash pile and hitting the delete key. There are cars and people moving around in it by default. And to my eye it is quite well done. It is so much fun at the moment. It is 100 gigs tho, so I'm calling it 100 Gig City. They also have Meta-humans, which are very realistic looking people, I mean past what we are used to. The animations for them are still a little stiff, but I am really amazed at what this thing does at this point. I will now simply migrate from TM to Unreal 5. Thanks ADS for the abilities to take advantage of this new capability essentially as soon as it came out.
  6. 1 point

    Unreal 5

    I have also discovered that exporting with the option to use layers as hierarchy allows me to use my standard way of organizing in Twinmotion. (duh) I have been forced to try to export to TM from both current versions of 3D StudioMax and Maya in order to try to shortcut using some Turbosquid content. In short, headaches, they do not produce usable results, and crash as well. This Twinmotion exporter for formZ is working like a dream, and I haven't changed the plugin it in over a year. There really is something great here. I take my final VRay model and export it. No geometry issues, no map issues, works every time. It is amazing to see a model I've worked on move around so fast. I just fix the material properties, re-do the lights with the presets, and off to the races. I am having some issues in Unreal 5, for example, the "Two-Sided" training wheels that Twinmotion has does not seem to be there, and everything is one sided until directly addressed.
  7. 1 point

    Unreal 5

    Hi dpwr, Glad to hear you are back home and on the mend. Yes, I too had client demand for immediate visualizations, also the ability to change them immediately. Wow, using TM for stage lighting and so forth is going to be a tall order, but I have been quite impressed with TM lighting and GI. I think bloom and lens flares get intense very quickly, but just to have those things is way cool. The TM interface seems built around a bit of discovery and ease of use, all the basic controls are there and you dig down into each item to change settings. After a year or more on TM, I find myself zipping around quite confidently and daring to do all sorts of things.
  8. 1 point
    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.
  9. 1 point

    High Memory Usage??

    Yes, I reported it to them. The entire Windows operating system fits on an 8GB thumb drive, so I don't think formZ should be loading that many libraries into memory with no files open... I think something is using memory it shouldn't.
  10. 1 point

    Unreal 5

    hi dpwr, Martin Krasemann's videos are in my opinion the easiest way to learn TM They are available on the Youtube channel Then there is an unofficial but very popular facebook page... For specific problems do not hesitate to raise the questions to the support If you see things that seem problematic and for which you can't find a solution, contact me jldaureil[at]alicepro.fr We can escalate to development manager through the restricted beta testing forum
  11. 1 point

    Unreal 5

    hi dpwr, Thanks for answering, and sorry to hear you are down, I wish you a speedy recovery. I am actually a whippersnapper with Twinmotion, I just did a 4k animation for a product launch that two years ago would have been considered a miracle. I can't make combined motions, and I want to import .fbx animation into it from outside sources. This is why I know I must take the Unreal 5 road now. I just am not good with the new lighting in it right off the bat. I will look into GI/lighting tutorials for Unreal 5, it is really awesome.
  12. 1 point
    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.
  13. 1 point

    Materials not visable

    Have you checked the face normals? Although if you display the face normals (Inspector>Attributes>Show face normals) on those high res people it'll slow your machine to a crawl (thousands of arrows) so I suggest moving your camera in perspective view inside one of those wire people to see if the texture shows. If it does on the inside then use the Reverse tool. I find this sometimes happens on some imported geometry. If that's not the case, go to the material parameters, select a problematic material and select shaded to see if the transparency is set to 100% or something like that. Some imports come in like that and have to be set to "None". Another thing to consider if none of the above works, is to check the image file for the texture. Some are png files and have transparency. When I have imported people for example (heavy geometry), I create lower res jpegs (Baseline Standard and not Progressive) of the supplied image textures. I use Maxwell and I'm sure there is an equivalent in Vray, but I create MXS files of the people so they are not actually in the main model file and are displayed as Boxes or dots. This helps to keep the model snappy and workable (slightly off topic). Des
  14. 1 point

    Unreal 5

    I have had some frequent crashing of Unreal 5 when the movie is rendered however (in 100 Gig City, to be fair), but after a reboot it has been able to re-do a bit of work. I have sent off the logs to EPIC. Just wanted to let you all know it wasn't bulletproof under load. Saving is recommended.
  15. 1 point
    Well I have figured how to successfully open obj files in 3DCoat 2022 from formZ 9.2 on a Mac. This was accomplished using the scientific method of flipping switches and turning knobs. In the export dialog window for obj, the user has the option to choose which operating system the export file is intended for. Instead of using the default which is Mac, I selected Windows. 3dCoat had no problem opening the file. Choosing UNIX also worked without any problem. Fbx was able to export from formZ to 3dCoat, but also would change scale, and change the axis. What a hassle. Not sure if the problem lays with formZ or 3dCoat. I really don't care at this point. By the way, 3dCoat seems really interesting so far. The texturing capabilities are a blast to use. Hope this helps anyone who's interesting using 3dCoat, which is nice software to own in conjunction with formZ.
  16. 1 point
    ¢hris £und

    MIMI updated :: Sort of

    Thanks for the continued interest in this script! dpwr, Yes, unfortunately, the capabilities of scripting have not kept up with the demands of the App itself. While I think it is great that ADS has activated FSL again, it is really only good in the absence of a complete alternative. That being Python, however, it Python is not near complete. Last I have looked, admittedly, is less and less often. The complete subtopic of dealing with materials is absent in the SDK/API. The script itself is not difficult, but is very dependent on the API. Justin, you are sort of right. However when writing a script or plugin for an existing product, a developer is highly dependent on the API of said product. Each product is going to have their own API. While the specific functionality of the code can be (but is not necessarily) independent of the API. All the connections, hooks, callbacks, interactions to the App and to the Users, etc... requires the API. So, there will be a lot of work to move code from one app to another. The exact same issue exists between Window and the MacOS. Though, nowadays, there are coding environments that do the middleman work of translation to make this process easier. Nothing like this exists, nor would I expect it to, at the App level. In my case, the code that I write is mostly glueing parts of the API together in a way that manages to do what I want to get done. There is a C/C++ API that may have the parts and components (classes and functions) to do so. However, the added overhead to do so is outside of my scope. Really, outside of my interest. I no longer use fZ for my living (or any CAD) and I am not a professional developer.a As mentioned above, I do think it is good to allow the old FSL scripts to work again. I also think it would have been better to move forward with gusto than to look back. I think I mentioned this earlier, ADS had no reason to even consider something like Python when they created FSL. Undoubtably, that was a lot of effort on their part. And Undoubtably, moving over to Python is a lot of work. I can only assume, it was a lot easier to reactivate FSL. Possibly they calculate that FSL will give them some breathing room to get Python fully running. My only concern is, I don't see anybody moving forward developing in FSL. Python or some other contemporary language is the future. FSL is not (IMHO.) I think that they have made some good moves lately, such as their partnership for 2D Cad etc... I suspect these efforts have pulled them away from further developing the Python API. I cannot disparage them, as I do not know the internal operations of their business nor their needs. At this point, I can only assume that they are doing what they figure they need. Do consider that we as users are pulling them in a multi-pronged tug of war. Each of us asking for what will be best for us. I do concur though, that adding functionality through plugins and scripts is important. That could offload all the details to users (scripts) and to other professional developer. Leaving the core functionality of the App to ADS. I will update the script when I get the tools to do so. Assuming ADS or somebody else doesn't beat me to it via the C/C++ API. Cheers, ¢hris £und
  17. 0 points

    Unreal 5

    Grrr... I am not finding Unreal 5 GI immediately manageable. It is somehow not Twinmotion, it seems like a file will need serious tweaking to get proper looking lighting. Also, it crashes under load and my surge protector/power backup at times begins screaming. It's not going to be such a picnic as was TM, but the city is very cool.