TheKitchenAbode
Members-
Posts
3070 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Everything posted by TheKitchenAbode
-
That will be very tricky to do. CA's standard text functions do not support 3D. They do have one 3D text set available in the bonus catalogs but it just seems to be some generic block type text. Not sure but maybe sketch-up might allow you to design the text portion and then you could import it into CA as a symbol.
-
Printed perspective drawings are very dark
TheKitchenAbode replied to Grayling's topic in General Q & A
I don't use any special calibration hardware/software, just do this by eye using some pics that I'm very familiar with and some free test patterns. What's important is that your monitors brightness and colour settings are independent of the actual pic's data, so the pic can look great on your screen but is in fact too dark. When you make changes in brightness, color, etc. in say Photoshop that data is stored in the pic and will be interpreted properly by the receiving device such as a printer. There may be something else going on but the first place I would take a look at is if your monitors settings such as brightness, gamma, color saturation is reasonably balanced. This can be done directly in your monitor settings or through your graphics card control DBX. When you do this you must face the fact that the proper settings may not always result in your screen looking right according to your personal preferences, many prefer overly saturated colors and higher than normal contrast, which is fine but when working with pics this will give you a false impression as to how your pic will really look when reproduced according to it's true data profile. -
Printed perspective drawings are very dark
TheKitchenAbode replied to Grayling's topic in General Q & A
your posted PDf's printed out fine for me. Is this something that has just started to happen or does everything outputted from your computer print overly dark? -
Printed perspective drawings are very dark
TheKitchenAbode replied to Grayling's topic in General Q & A
An example would be great. Maybe it's the printer settings that are the issue, most printers have setting controls that allow you to adjust brightness, contrast, colour saturation and more so you can align/calibrate the printer with your screen. -
Stone material/River Rock, Pebble Stone
TheKitchenAbode replied to jjifmeyer's topic in General Q & A
The library search could be better but in your situation I think you were misinterpreting the fact that when you search it only searches the libraries currently installed on your system, there is no online search feature that looks at all of the available library catalogs. -
Those 6 cores are maxing out all the time, it's just that due to lower complexity the duration is very short so they may only be maxed out for a few milliseconds. Same for my HD620, maxes out when rotating and zooming in 3D.
-
Tried again and it loaded in. That one is more brutal than my Stress Test P-Solid as it adds a crazy number of surfaces, around 16 million. Now plan panning and zooming are impossible but opening up a camera view takes considerable time.
-
I get an error when trying to open this plan. The CAD blocks are the issue, way too complex, they should just be a perimeter outline without all of the internal vector lines. Turning layers off has it's limitations, works fine unless the layer you need to work on is the one that contains the bulk of the plans vector lines.
-
You are very welcome. One other thing, the 3D model rebuild is really only applicable for camera views. A plan view is distinctly different, if panning and zooming is starting to slow down then turning off display layers can be highly effective as this will reduce the amount of vector graphics.
-
Yes, but not in all cases. The 3D Model rebuild, which is likely the most time intensive process can be controlled to a certain extent via the display layer options. However, there appears to be circumstances where CA seems to ignore the display layers and performs a full 3D Model Rebuild.
-
You may have to find some other plant model to use for the hedges. Some of those 3D plants are extremely complex, the 2D plants are much more simple.
-
Did the slow down happen after you put those hedges in?
-
You have intentionally or unintentional added something that has significantly increased the complexity of your plan. CA now has to do a crazy number of computations to build the 3D model when you open a camera view. Difficult to say exactly what item(s) it is without the plan but I'm wondering what that dark area is right side of exterior wall. Are those maybe hundreds of 3D plants?
-
This is when upgrading is warranted when plans increase in complexity to the point that lag starts creeping into the system. The stress tests are designed to help identify the different causes of lag and hopefully provide some guidance as to the most effective approach to resolve this. I believe it is evident that for your situation the video card has nothing at all to do with the lag you are experiencing, you have 24 GB or system memory so there should be no issue there. Everything tells me that you are just running into certain limitations of those Xeon CPU's. Seeing a specific plan that you struggle with might provide some further insight into this.
-
It is accurate, that's the reality of what's going on. Another great example. CA only needs what it needs to do the job. For example, in your vid you rotated/moved around the model. How fast you moved the mouse dictated the number of frames needed to reflect that degree of motion and for each frame the lights and their effect had to computed. The rate is being dictated by your mouse movement. Though simplified, each move of your mouse is equal to some distance, let's say 12", if you scroll 10 feet then 10 frames need to be generated to reflect that movement, not much work for a 1080 card that can easily crank out 60 or more frames per second.
-
Good example Larry. If you are PBR'ing without a lot of active lights your GPU is not going to be stressed. Each added light requires additional computations to calculate the effect on textures/surfaces, reflections, etc. Also, as you add lights your GPU memory usage will increase, I have ones where one scene eats 4 GB or more. If you were to throw in say 100 active lights and have all camera options checked you will notice a significant difference in your GPU usage as you move the scene. So the take on this is if PBR'ing with complicated lit scenes is not really part of your workflow then there's no real benefit in spending crazy amounts of money on the latest and greatest video card.
-
I'm certain this would happen, as with any software at some point things will start to visibly slow down if you give it enough to do, it's the nature of the beast. Though the relevance of these stress tests may be disputed, their results and what they reveal concerning the varied processes appear to be clear. They may also go against conventional generalizations but I don't really have any control over that, the facts speak for themselves. So far the stress tests have primarily revealed CPU related processes, will now try to develop tests that will hopefully provide a means to better quantify video card and disk drive relevance.
-
I'll send you my address so you can have one dropped off in my driveway for a test run. Results won't be very good though, with our traffic conditions about 60 miles an hour is tops and there are traffic lights about every 2 blocks.
-
Much appreciated Rene, my thoughts are mutual. I knew from the beginning of this exercise that aspects of this would raise controversy. The purpose here was not to purposely prove or disprove anything, it was intended to allow one, including myself, to better understand some of the things that are going on when working in CA that can impact on ones workflow experience. The derived results are not to be taken in absolute terms, they are to be viewed from a point of relativity to and with the other results. It is extremely important that one does not attempt to extrapolate these result beyond the context of the tests design parameters. The tests were not purposely designed to be biased towards any specific hardware setup, but they are biased from the perspective that they were designed to evaluate a very specific function, and it is the processes involved in executing this function that defines the role played by the hardware. The fact that the tests force CA to process plans beyond what one normally works with is by design, otherwise the involved processes would not be revealed. It's no different than using a high speed camera to allow one to examine fast moving things through slow motion. If not for this type of technique we would still be arguing over whether or not all 4 hoofs of a horse left the ground while galloping. Do other elements factor into this performance issue such as caching, memory speed, ram disks and the likes, I'm certain there are but to date I have not seen any quantifiable data specific to CA to demonstrate this. I have read many technical documents concerning the impact these can have, the issue is that in many cases their degree of benefit is highly dependent upon very specific processes. Added to this is the fact that some of these techniques do not, due to other significant hardware improvements, have the same degree of benefit as they did at the time of their original evaluation. I'm also a bit hesitant to go to far into these as those techniques are in most cases outside of the average users expertise.
-
Thanks Mike, that makes sense. Really appreciate your participation.
-
Correct, that's what the stress test results are demonstrating. The same can be said for the GPU, as we have seen so far systems with top end GPU's do not demonstrate improved performance relative to their stated(independently reviewed) gamming performance differences. The tests demonstrate that depending on what type of function one is doing that what impacts on performance varies. It is clear from say the BBQ test that processing surfaces/textures is a mult-threaded operation and as such high core count processors will be beneficial. On the other hand the P-solid test demonstrates that in plan views vector graphics manipulations are mostly single threaded and as such high core count processors do not provide a significant improvement. Though I do not have a test bench here to swap out specific pieces of hardware there are all of the differing systems out here in the forum. They can run these and report their findings and as being demonstrated there are indicators of certain trends. I'm more than open to other testing examples/methods to demonstrate other performance aspects. I'm even open to other tests that disprove the conclusions being drawn upon based on my tests.
-
That's due to the fill I used, if you open up the object and reduce the fill spacing from say my 1/16' to say 1/4' you will see a significant improvement in performance. That fill creates a crazy number of vector lines that must be recalculated when scaling up and down when zooming.
-
There's no doubt so far in the three posted stress tests that the GPU's role is very minor and that certainly raises the question as to the value of spending big bucks on the most powerful GPU out there. Also, other than PBR'ing there are no indicators that one needs massive amounts of GPU memory, it's just not being used. However, keep in mind that these tests are focused on CA's needs only, you may be running other software on your system that may benefit greatly from a high end GPU.
-
I have asked if Mike if this could be confirmed as the number of 11 sec to open the camera in the BBQ test seems way too low according to his systems specs and when compared to the numbers being reported by those with I7 -9700K and I9 - 9900K CPUs. The AMD is a good processor but I have never seen a comparison review that shows it beating those processors.