HalTDavis

I've taken a couple of courses in logic and programming, and I'm kind of new to vectorworks, but I see two possible routes here. The first is putting in a minimum and maximum Lux value, a geo-reference and position data for where the sunlight would come from (which would require you to set up a light source that would serve as the sun), select a general shape\ratio of sizes of sides\perimeter for the holes (thickness could come from the wall object), you'll also need to know how far from the edges the holes need to sit, and how far apart you want them; and set up two layers with both the maximum and minimum number of holes based on that info. Another way is to give it how many holes with all pertinent sizing, etc, and getting back a LUX value in the room, which is just a light meter in different corners. You'd still need many of the components from above. Here's what I would do.... ...Seating charts are already built into Vectorworks. You can use that tool with special object you create (a 3d shape of your holes), and then set the seat counts to change the number of holes per row, and set the vertical distance to change the number of columns. You'd have to create the LEG and SEAT marks in your shape for VW to use, but it would give you a way to populate the surface instantly, and ctrl\command +Z to go back and do over. You'd have to get the data from one hole first, placed in different random areas, by subtracting it from your wall, then measuring the light from it, to give you an idea of how big it would have to be to get the right amount of light at it's outer falloff, which should be about 1\3 to 1\2 of your LUX needs for lighting in the darkest part of the room. You'll also need to know what those needs are for how bright it should be. Measure where the extreme falloff begins from the center of the beam of light, and set your distance between seats to match that or just a little more than that by up to 4' for every 10ft of ceiling height. You'll have to create a 2d planar shape that matches your ceiling or wall shape so you can create the seating chart, but once you do, you can align and ungroup the seats, then subtract each one from the wall. Just remember that you'll have to align the plane of the seats on your surface in 3d, so alignment options would be useful to you for align Left\right\center, top\bottom\middle, and you may have to use the rotate tool.

Just wanted to throw one in here... ...Thanks for asking the question, thanks for the answer, and generally, thanks to Nemetschek who built this software. For me, nothing ever goes 2d to 3d, it always goes from 3d to 2d--something my dad taught me when I was trying to draw the diagrams for a project for school that required some wood construction. This is an old thread, but it's been a while for me and the software is very different from the old 1990's MacDraw I used for a long time. There are some nuances I'm still learning and this is one of them.

I tried it today with a new file. I rebuilt everything in the old file. For some reason, the polygons are acting up again and it isn't my broken file. Somehow, the rendering engine is fouling up, possibly due to the number of objects, I can't be sure without knowing more about the engine's limitations. I did put in cameras, tried the renders again, and again the polygons hated me. However, OPENGL worked fine. I even set the render settings high and it worked really fast. Check to make sure that your objects are not grouped in weird ways, or that your classes conform to norms. It may be something to do with that. Again, I can't be sure. I tend to reclass every set of objects to it's own class, and then put similar design elements (similar purpose) into the same layer so I can change how I work with the objects very quickly (altering class to only the active allows me to see all of one type of object so I can move them around; prevents grouping problems). This method worked at first with one or two objects, but I'll admit I've got 40 children placed. OpenGL has a cleanup designed to limit memory leakage where the polygon shaders don't seem to. From the Cameras, I created viewports and only opengl worked. I stuck with it. I'll try other renderworks styles later, but I get the feeling I'd be better off sending to Cinema4d for a full render.

I opened a new file, blank. I used a basic wall. I rendered in several different modes. It's not renderworks. It's my file. At first, it worked, and I'm guessing the polygon styles don't like textures. I also have a lot of collisions between my own extruded spacers and it may be that the polygon renders are having trouble with those. I tried with and without Admin rights. Oddly enough, without admin rights everything processes through open gl a lot faster. If both VW and RW are set to normal compatibility, it's fast. I'm going to guess that there's a system check that occurs in the function to startup the render, then in each function that calls system based api's rather than the RW api. This causes small but noticeable drops in opengl. The coolest part though is that opengl will render out just fine, and I ran a benchmark on my cards, my intel cpu gets every message, but only outputs about 1\4 of the info back into the program, while my NVIDIA GPU (980m) will output the rest, and still get it all. My best guess here is that SLI or and IRIS variant is running in the background to balance the weight across the two. The memory processes when the crash occurs fill up with error data, and neither processor does anything. It has to be the textures. I'll turn them off. I don't need them so much, only to visualize differences in objects. Perhaps a solid color can provide that. Textures that are 2d and placed on 3d don't work well with polygons that are colliding so much (overlapping). That's why they have such a problem. I'm uploading my project file. Check the spacers between the child models. They have a class texture applied. Try rendering. It may be that the latest version of renderworks does not like my work there. No biggie for me, but others may have a problem. Disney_Stage.vwx Update2: More testing reveals the culprit. Check your classes and layers for any settings that apply patters with opacity shading added (IE turning down the opacity from 100 to something lower). The pattern and the shading won't work together. If you use a solid color, it will work fine. Textures won't work either. However, if you send it to a full rendering with all lighting and adjustment, it seems to work fine. The render engine for the pattern and opacity seems to error out. I tried removing them but it still wouldn't render, then I removed the classes and anything they actually affected. It rendered once, then when I did it again, crash. It's a memory leak alright, but where is still unknown. At some point in the render, it's still finding the error data. Best to PURGE anything unused and try again. The file here is the broken one. DO NOT RENDER PATTERNS with polygon settings, do not render patterns at all with opacity, this fails even with opengl or renderworks styles. If you're going to render them with patterns or texture, I suggest you save the texturing and patterning steps for the end. I rebuilt the entire file from scratch. Without the patterns, everything renders fine. Problem possibility 2: When closing the device for sleep, leave the files open in vectorworks, or if you shut it down, shut down the entire computer. I closed it up and it probably prevented some of the data from being unlocked by the program (database files end up locked while their being worked on, and what you actually edit is an editspace which applies at the next save operation; this allows the system to hold a pagespace of memory for the database file, and an open memory space with a pagespace backup for your edits; when edits are made, they are tagged onto the end of the database pagespace, and then the file is rewritten when all access to the file is closed; most apps like VWX use exclusive access for standard desktop clients, and shared access for larger server connections, allowing the maintenance of the file to run when the access to the file is closed out from the last machine accessing it, or at a set time for servers). I may have inadvertently prevented the rewrite in some fashion or broke the file linkage somehow. But the graphics stuff I outlined above shows up in new files too, so it's definitely a possible cause for my problem, and likely yours.

I have now gotten the same problem. I render with Polygon unshaded, and only one of the items has any texture to it. There really isn't much there; a small stage, some spacers and some people. I rendered it yesterday and it was fine. Now it crashes every time I use a polygon mode. What gives? I've tried everything from moving pieces into another file to adjust my graphics card values for that program to resaving the file. I'm going to try exporting to 2016 next. I'm wondering if there isn't a problem with Renderworks that requires admin status. Renderworks won't use a Graphics card to Render Graphics? There's a new one. I used to play around with those problems when dual graphics modes were first showing up; ultimately, most programs were written to grab the first processor in the graphics path, and when it was a CPU, they would crash because the CPU didn't have the instruction architectures that Graphics cards had, and all the while the program was actually seeing the graphics card as being the place to send the instructions, so all the API calls and values were built for a piece of hardware that was down the line, just past another piece of hardware. Unfortunately, it appears that renderworks has somehow fallen back into this problem. My main CPU should only use about 1-2gb of ram for graphics, but my secondary card has 4gb. It's easy to tell why I want to use one over the other. I've had issues in the past with some programs needing ADMIN rights if they use graphics. The first time they run, everything is ok, but afterward, they are flagged and there's no dialogue to allow them admin access if they are called by another program. I'll search that out first and let you know. Update: I opened a new file, blank. I used a basic wall. I rendered in several different modes. It's not renderworks. It's my file. At first, it worked, and I'm guessing the polygon styles don't like textures. I also have a lot of collisions between my own extruded spacers and it may be that the polygon renders are having trouble with those. I tried with and without Admin rights. Oddly enough, without admin rights everything processes through open gl a lot faster. If both VW and RW are set to normal compatibility, it's fast. I'm going to guess that there's a system check that occurs in the function to startup the render, then in each function that calls system based api's rather than the RW api. This causes small but noticeable drops in opengl. The coolest part though is that opengl will render out just fine, and I ran a benchmark on my cards, my intel cpu gets every message, but only outputs about 1\4 of the info back into the program, while my NVIDIA GPU (980m) will output the rest, and still get it all. My best guess here is that SLI or and IRIS variant is running in the background to balance the weight across the two. The memory processes when the crash occurs fill up with error data, and neither processor does anything. It has to be the textures. I'll turn them off. I don't need them so much, only to visualize differences in objects. Perhaps a solid color can provide that. Textures that are 2d and placed on 3d don't work well with polygons that are colliding so much (overlapping). That's why they have such a problem. I'm uploading my project file. Check the spacers between the child models. They have a class texture applied. Try rendering. It may be that the latest version of renderworks does not like my work there. No biggie for me, but others may have a problem. Disney_Stage.vwx