Author Topic: RedSDK Feature in DesignCAD  (Read 1253 times)

ALI ZAIDI

  • Beta Testers
  • *
  • Posts: 21
RedSDK Feature in DesignCAD
« on: April 19, 2018, 11:29:40 PM »
Hi All

IMSI has decided to disable RedSDK from DesignCAD. This is because they have terminated their contract with Redway which is the parent company of RedSDK.
Now for rendering we have OPENGL and GDI. We are looking into Lightworks to potentially replace RedSDK in DesignCAD. What is your opinion on this matter. How frequently do you people use RedSDK?
And moreover Lightworks will be integrated in the next release if possible. Any other possible rendering third party tool we can integrate in DesignCAD?

Your opinions will be appreciated.

Thanks 
Ali Zaidi
DesignCAD Developer
IMSI Technologies

Rob S

  • Hero Member
  • *****
  • Posts: 4549
    • Construction Estimating Program for General Contractors
Re: RedSDK Feature in DesignCAD
« Reply #1 on: April 20, 2018, 07:31:08 AM »
I always though RED was very inefficient in its use of memory and did not seem to interact well with Designcad.  So, no regrets on my part - except

We have the issue of very slow redraw of rubber band lines in GDI mode when working in 3D shaded view, making certain operations almost impossible.  The following thread has more info

http://forum.designcadcommunity.com/index.php?topic=6828.msg49087#msg49087


I hope you can find some way to make this work better in native mode.

I also wonder if it might not be easier and more productive to work on Designcad's own rendering engine, as it is already well integrated.

Any third party product always leave you subject to the whims of the third party, who knows how much effort was expended to make redway work, now all for nothing!!!
« Last Edit: April 20, 2018, 07:35:22 AM by Rob S »
User since Pro-design

Lar

  • Hero Member
  • *****
  • Posts: 2828
Re: RedSDK Feature in DesignCAD
« Reply #2 on: April 20, 2018, 11:21:18 AM »

How frequently do you people use RedSDK?
Red was way too problematic to ever use consistently! Plus, in dcad it couldn't do what the Red website was bragging it could do.


Just the simple implementation of mixed mode shading was a life changer for me. Let's say our goodbyes to Red and get this Lightwave thing underway immediately!!!


Lar
« Last Edit: April 20, 2018, 11:23:28 AM by Lar »

Dempsey

  • Hero Member
  • *****
  • Posts: 1916
  • Intel i7-960, 12GB, NVidiaGTX570, Win7x64, DC27.0
    • World of van Vliet
Re: RedSDK Feature in DesignCAD
« Reply #3 on: April 20, 2018, 02:13:29 PM »
RedSDK integration was never fully completed. There were outstanding issues while drawing, glass rendering was not transparent, paper space did not work properly in RedSDK mode, etc.. So I  mainly used it for 3D viewing while rotating the model as that was very fast.

Yes, I look forward to the complete integration of DesignCAD with Lightwave.
Dempsey

JJG

  • Hero Member
  • *****
  • Posts: 737
Re: RedSDK Feature in DesignCAD
« Reply #4 on: April 20, 2018, 09:28:58 PM »
And I would add to this that I suspect that the OpenGL mode display slowdown observed after V21 may be linked with the introduction of Red in DesignCAD.

Developers of DesignCad : please look how Designcad's display was fast befor and up to V21 (in drawings of more than 5 MB with nested groups and improper solids).
After, once the inroduction of Red, everything has become so slow ... so much so that personally, for drawings of more than 5 MB, I continue to use V21 !!!

Dr PR

  • Hero Member
  • *****
  • Posts: 5653
Re: RedSDK Feature in DesignCAD
« Reply #5 on: April 20, 2018, 10:56:13 PM »
I did not see any reduction in drawing speed in native DesignCAD rendering modes (GDI and OpenGL) after the introduction of RedSDK. To the contrary, timing results posted by several Forum members showed either no changes or some enhanced drawing speeds.

RedSDK was never actually implemented in DesignCAD. It could never do what the native DesignCAD rendering engine could do (smooth shading, shadows, etc.), so I never used it except for beta testing. However, the small part of RedSDK that was implemented was many, many, many, many times faster than the native rendering modes.

I was a staunch proponent of RedSDK, and enthusiastically tested it, but only because the native DesignCAD rendering code is so screwed up! It dates back to Windows 3 in the early 1990s and is the worst rendering I have seen in any 3D product. Many freeware programs, and cheap programs like AccuTrans 3D, have rendering code many, many, many times faster than DesignCAD, with lots more features (like ray tracing). Basically, ANYTHING would be better than the native DesignCAD rendering code!

I have listed the many problems with the native DesignCAD rendering several times on the forum. Here is the short list:

1. Very slow redraws. Initial shading in OpenGL Gouraud can take 30 minutes or more (90 minutes with a 750 Mbyte file). After that in a large (>100 Mbyte) drawing a screen redraw can take 10-20 seconds for each open window.

View rotation (Set View by Drawing Center) in large drawings is extremely slow and spastic, with new images every 10-20 seconds, making view rotation very jerky. With RedSDK there was no noticeable  hesitation in display rotation, not even with the largest drawings I have tested (750 Mbyte files with more than a million objects). Even the cheap Accutrans3D program rotates large drawings smoothly with no hesitation/jerkiness.

2. Repeating redraws. Every time DesignCAD redraws a window, it repeats the redraw several times - at least twice, and sometimes four times.  Each open window is redrawn up to four times. First the main (current window with the focus) redraws, then every open window redraws, redraws again, redraws again, and redraws again. This is just screwy!

If you are working in Point Select mode and have objects selected, redraws are doubled.

With large files (10-20 seconds per window) this is VERY noticeable! It can be nearly impossible to get anything done with four windows open, so working with large files is restricted to a single window, and that can be excruciatingly slow. I have posted detailed timing descriptions elsewhere on this forum.

3. Unnecessary redraws. If you change from rendering mode in the main window all the other windows redraw. Changing the rendering mode does not change the drawing in any way, so why would changing the display in one window cause the other windows to redraw?

4. Shadows are totally screwed up in DesignCAD native rendering modes (OpenGL Gouraud and GDI Phong). The maximum number of shadow "squares" is 2048, and these are based upon the total drawing size, and not the part of the drawing that is being rendered. This is just wierd!

If your drawing is 2048 units wide (whatever drawing units you use) each shadow square is one unit per side. So if you zoom in to view details 10 units wide the shadows are rendered in one unit shadow squares, and look something like a checkerboard - horribly ugly and totally useless!

Shadows of tall thin objects (poles, antennas, etc.) render as two parallel lines - really ugly!

The "new shadows" implementation was an effort to fix this mess, but shadows were only rendered for a square area that often did not include the total view area. So parts of the view had shadows and other parts did not. New shadows worked fairly well for the screen display, but they were never implemented for the "File/Image/Save Image File" process.

Shadow options (Options/Options/Light Source/Shadow Options) include a "Shadow Tolerance" slider. Does anyone know what this is supposed to do. With any setting other than 0% shadows wander away from the objects casting them. For example, the shadow cast by a table leg sitting on a floor will appear in the distance from the table leg. ?WTF, over!

5. Lighting effects are totally screwed up in DesignCAD! Objects have material properties that should give them surface effects like shiny, dull, etc. But the LIGHTS also have shiny, dull, etc. properties. So you may have an object material that is highly reflective or shiny, but if you use a light source  that is dull (not shiny) the shiny material will render dull! It is like saying chrome plated metals will be shiny if you use a flashlight to illuminate them, but dull and not shiny in sunlight!!  This is just about the stupidest thing I have ever heard of!!!

Lighting is totally schizophrenic and unpredictable in DesignCAD.

6. Image files. The results of "File/Image/Save Image File" are not consistent. If you save the same image with the display in Wireframe, Gouraud and Phong modes the saved image file will be different for each screen display mode. Totally screwed up!!!

7. Reflections. Native DesignCAD rendering cannot produce a reflective surface like mirrors, shiny chrome metals, or just reflections on glass surfaces.

8. Transparency. Enabling transparency (for glass) slowed rendering to a crawl. I had a 50 Mbyte file with one glass object in it. With transparency disabled the image would redraw in a second or two (after the first rendering which took 10-20 minutes). But when I enabled transparency it took more than 90 minutes to redraw (I used Task Manager to kill the program after 90 minutes). I don't know how long it would actually take to complete rendering with transparency enabled in a really large drawing - maybe longer than the universe will last.

***

NOTE: These timing descriptions are based upon a 64 bit i7-3930K six core processor at 3.2-3.7 GHz, 64 bit data bus with 32 Gbytes 1.6 GHz memory, and a Nvidia Quadro 2000 display adapter. The processor has a dual fan liquid cooler to prevent processor delays due to overheating.

When I refer to "large" drawings I mean >100 Megabyte files. I sometimes work with files up to nearly a gigabyte.

****

DesignCAD V15 did not have any of these display bugs (it also didn't have shadows). All of these problems were introduced in V16 and later.

Because DesignCAD native rendering has SO MANY bugs I embraced Red SDK simply because getting rid of the native display code might get rid of the bugs. In other words, anything else should be better! Red SDK Wireframe and quick shading were many, many, many times faster than native DesignCAD rendering, proving that it is possible to improve DesignCAD rendering.

 I am a bit pissed that we wasted so much time with RedSDK. I suspect the problem is not with RedSDK, but is caused by the suits who run IMSI who will not give DesignCAD the programming support it needs.

If you are going to switch to Lightwave - or anything else - don't screw around with us again by switching after a year or two.

Before changing to anything else just fix all the bugs in the existing code!

Phil
DesignCAD user since 1987

Lar

  • Hero Member
  • *****
  • Posts: 2828
Re: RedSDK Feature in DesignCAD
« Reply #6 on: April 21, 2018, 12:07:45 PM »

Red mode IS capable of impressive real time orbits. Other than that it is a huge mess.

Having to learn Cinema 4D (which uses similar display tech as other real time rendering apps, I assume) while using Dcad meant I had to understand the difference between the two. Below is a list of what I have learned about Dcad's display issues from C4D, and some from Dcad itself:

1] Dcad's native rendering was hampered by one of its unique strengths: Individual Plane surfaces that can have any number of points, not just 3.
 
2] The fact that Solids consist of Planes and Grid Surfaces results in edges where the 2 entity types would meet, meaning twice the calculations for the same edge.
 
Other 3d software use a "point cloud" for its solids. The surfaces you see are defined by which 3 points they each use. Now, in my mind, this technique should be slower but in reality it's what makes real time pans, zooms and orbits possible. It's also what makes non-destructive booles possible because the software can, on the fly, change which 3 points define surfaces, or even temporarily add new points to cater to the booling solid. In C4D, with internal edges visible, you can see the edges of the 3 point facets changing in real time as you move a booling solid through the host solid.

DT&Co tried to fix this situation with the 'Surface Solid' entity (and by making dcad 64 bit) but I couldn't see much difference in Red's orbiting speed, it was actually very fast either way. I guess normal Solids aided and abetted Red's other issues.

3] Dcad always renders at a high entity fidelity. Other software would lower it accuracy for the sake of orbits and lowers its display for working in shaded modes.

4] Dcad's 'Set View' command (Y) calculates for all the visible entities as opposed to what's currently visible in the active window. To test this get a reasonably large file, turn on most layers, zoom all and use Y. Then, zoom in and use Y again. There would be no difference in the orbiting speed. Now do the same with the Move-Left, Right, Up and Down arrows in the View Toolbox. The less stuff visible in the window the faster the orbiting (hold the mouse button on the arrow button to 'orbit').

5] IMO, Dcad traditionally is very hesitant to delve back into what programming is already written. I mean, I'm an architect with deadlines to meet but I would allow a few hours to write a macro. Many times I then see other possibilities so I would allow more time for enhancements. When done, even if it took 2 more days to perfect the macro, I have something that would serve me for years and years to come. Dcad does not do this. It could take 25 years to make a simple enhancement, like mixed mode rendering. The biggest casualty of this philosophy has been its display algorithms. When you zoom, dcad still redraws each entity one by one (wireframe, of course). Other software just re-draws everything in one go. I remember back in the early 1990's when autocad use to also do this but soon after it had display dlls that did instant redraws and allowed real time pans of the whole drawing, even what was off screen when the panning started. Dcad still only pans what was onscreen when started, so it obviously just grabbed a bitmap of the window. Back in the late 90's, when the forum was young, I suggested a feature where a solid could cause invisibility in another solid. So, eg, you could put a box in a wall and it would appear like a hole was in the wall, for windows and doors and such. Of course my idea was completely ignored. A year or two later a colleague invited me over to check out his new software. One of its features was doors and windows that automatically created non-destructive holes in the wall it inhabited. That software was called Chief Architect. Dcad still can't do this, even in Red mode.

6] Dcad still lacks physical cameras objects that you can place anywhere in the drawing and simply rotate to focus on a view, and then at any time later activate a camera to get that view back. I mean, come on, man! Me, a lowly architect with no formal programming training, I have my own camera object (dubbed the LarCam, of course) that I can place anywhere and it positions itself according to the view of the window. Later I can select that camera to recapture that view, whether it's a parallel or perspective. Dcad's 'User Defined Views' is the closest thing to this but it saves views in the Window's registry or something, not in the file. LarCams are far more robust though. They can also save an image of the exact view the camera frames, in whatever display mode, dpi, layer setup and image name the Cam stipulates. When dcad does its wacky back-and/or-front-camera-cutting-plane nonsense the LarCam allows for the recapturing of the parts of the image that dcad discarded.

7] As for Dcad's wacky back-and-front-camera-cutting-planes, please fix this nonsense. I have only recently discovered (this year) that Dcad's front cutting plane always cuts midway between the viewer position and the focal point.  (I haven't yet uncovered how its rear-cutting-plane operates). Now, knowing where the front plane cuts is beneficial in that I can create a non-destructive slice through a model where ever I want it to be. That is very significant, but when it comes to presentation meetings where I'm moving through a model, things being cut away is really confusing for the client. Dcad's front cutting plane should be at the camera or slightly behind it. Not anywhere in front of the camera. The rear cutting plane should be done away with, or optional. We should also have optional free front-cutting planes, that can be placed anywhere and angled anyhow.


8] Constant Shading. Now that we have mixed mode rendering we can have constant shading. The black outlining of stuff means dcad can ignore the shading differences caused by the different angles of surfaces and just color stuff their entity color. This should speed up orbit tremendously. Plus, surfaces parallel to the viewing angle seem to always render solid black (ie, lacks lighting) and constant shading will do away with this.


Lar
« Last Edit: April 22, 2018, 06:18:28 AM by Lar »

Dr PR

  • Hero Member
  • *****
  • Posts: 5653
Re: RedSDK Feature in DesignCAD
« Reply #7 on: April 21, 2018, 09:53:48 PM »
Lar,

I think I recall DT saying that for RedSDK rendering the entire drawing is regenerated in triangles - basically a point cloud. This wasn't too difficult because for many versions now (since V16?) rectangular facets were actually generated as two triangles with congruent hypotenuses, and the hypotenuses just weren't displayed in Wireframe displays. This helped "bend" grids through complex curvatures.

You can see these hypotenuses by generating surface intersections with grids , selecting the intersection lines, and enabling Point Select mode. Somewhere in the intersection line across most grid surfaces there will be an intermediate point between the points at the edges of the facet. This intermediate point is where the intersect line crosses the hypotenuse.

***

Thanks for mentioning the totally screwed up way DesignCAD works with the view. It was obviously created with external views in mind - as if you were viewing an object on a display stand. The View Center is on or inside the object, and the View Point orbits the View Center at the View Distance. This is OK for viewing the entire drawing from a distance. But it is like having the view camera fastened to one end of a pole with the other end fastened to the object to be viewed. The camera can point only at the object (View Center) and cannot be rotated to any other angle to view other objects without first repositioning the View Center on the desired object. Very cumbersome!

This is totally non-intuitive if you are trying to "walk through" a drawing to view from inside the drawing space. Instead of positioning the "camera" and rotating the view around the camera (the View Point is fixed and the View Center rotates around it) you have to manually move the View Center to change the view angle. Arrgggghhhh! This is horrible!

What we need is a view that works exactly like a camera - point the camera (rotate the view around the View Point), and change the "zoom" (View Distance) to frame the view of the part of the drawing we want to see.

Phil
DesignCAD user since 1987

JJG

  • Hero Member
  • *****
  • Posts: 737
Re: RedSDK Feature in DesignCAD
« Reply #8 on: April 22, 2018, 11:20:37 AM »
And I would add to this that I suspect that the OpenGL mode display slowdown observed after V21 may be linked with the introduction of Red in DesignCAD.

Developers of DesignCad : please look how Designcad's display was fast befor and up to V21 (in drawings of more than 5 MB with nested groups and improper solids).
After, once the inroduction of Red, everything has become so slow ... so much so that personally, for drawings of more than 5 MB, I continue to use V21 !!!

The reduction speed of DesignCad (due to regenerate) I'm speaking from is not in 3D rendering only, but in 2D working too ...
Also, I repeat it here : since V23 and later, for us the french users of DesignCad, DesignCad is so slow when working with drawing of more than 5 MB with nested groups and improper solids.
Please, give a look on this problem.

DrollTroll

  • Kindly Curmudgeon
  • Administrator
  • *****
  • Posts: 4231
Re: RedSDK Feature in DesignCAD
« Reply #9 on: April 25, 2018, 05:56:13 PM »
Some other 3D rendering options to consider:
  • VRAY Renderer
  • KRAY Renderer
  • LuxRender (main web page down, but still downloadable and next version under development)
  • TheaRender
Also, consider updating the OpenGL portions to a newer version of OpenGL (still locked at a very old core OpenGL feature set).
It may be worthwhile to investigate Direct3D as an alternative to, or additional option to, OpenGL.
Basically any near-realtime 3D rendering solution that also supports realtime view rotation and editing of geometry would be welcome, even if that solution isn't what gets used for the 'beauty' renders.
Lightworks was the engine behind an experimental rendering tool we played with in v18 beta -- some of the beta testers were disappointed it didn't go any further. Now perhaps it can (and also should be faster, since Lightworks will be directly integrated into DC, rather than scripted to an external engine).
25 years with DesignCAD

The Scud

  • Hero Member
  • *****
  • Posts: 759
Re: RedSDK Feature in DesignCAD
« Reply #10 on: April 28, 2018, 01:25:38 PM »
Rob and Lar, you guys hit the nail on the head! I have never used RedSDK, yeap let it go.
BETA man and proud Kiwi. aka Steve The Kiwi
Supreme writer of DesignCAD Tutorials
Toshiba L50 Laptop - It is OK.
Intel i5-337U @1.8GHz, 12 gig RAM, 64 Bit Win 10
Intel HD Graphics 4000 NVidia GeForce GT 740M
Desktop AMD A8 R7 64 bit Win 10 with Quadro K620

bdeck

  • Hero Member
  • *****
  • Posts: 925
Re: RedSDK Feature in DesignCAD
« Reply #11 on: April 28, 2018, 06:06:40 PM »
I'm with The Scud. Never used it, never cared.  Fix the dimension bugs before diving into another big project.