An exact definition of what is needed in haedware and software etc to run TFPlan with hardware acceleration truned on for design/build/render?
Can we also get a bit more response from the 'management' please, pretty please?????????????
Minimum System Requirements
Microsoft
Hi Dave,
Thanks for the info, it's good to have input from IMSI on this Forum.
However the info you quote is just the same as on the Website. What we really want to know is the minimum version of OpenGL required for Hardware Acceleration to work, as Doug asked previously, http://forum.turbofloorplan.com/index.php/topic,21.msg74.html#msg74 (http://forum.turbofloorplan.com/index.php/topic,21.msg74.html#msg74). 'With OpenGL driver' is not sufficient.
A statement like 'with OpenGL driver 100% v 2.1 or above' is needed.
(My card is 100% Open GL v1.2, but 0% v 1.4 and above - so will be no use if the requirement is higher than v1.4 - which it probably is as I believe v3.0 is the latest version.)
This is a question I asked many times on the old Forum and Beta Forum about v10 and v11 - but no one from IMSI ever answered - so my advice has always been 'if in doubt - turn it off'!
It looks like it's going to be just as big an issue for v12 - "turn it on for drawing, off for rendering", etc
Thanks.
This lack of specific and oft requested information is, frankly, unacceptable. It is 2007, not 1907 and customer do have the inteligence to use such information in the use of packages like TFPlan.
Dave, not intending to rant at you but can we please have the full monty and not the abridged version??????? Please!!!!!!!!!!!!!!!!!!!
Um, does *anyone* outside IMSI have a PC configuration which supports HA ??
---
To repeat my previous query on this subject, how about a small go/no-go test-program ??
As an alternative, perhaps we could devise a variety of cunning micro-plans which do/don't render with HA on reference system vs community systems ??
---
FWIW, FreshDiagnose is free to down-load and use, will test & report many aspects of hardware & software...
( Their e-mail with free registration code is followed by cheerful news-letters which are not quite frequent enough to classify as Spam...)
But what factors apply to HA ??
I remember first trying FreshDiagnose when we had the VERY SAME issues with FP HA compatibility...
Was that in v8 ?? D'uh...
I'd built my first CAD_PC *specifically* as an OpenGL 'screamer' for v6. Current Tower_2 is again optimised for OpenGL, has scary OpenGL through-put on 'random' drawing tests, the trade-off again being slow DirectX flood-fills...
I've usedWin'98r2, XP_SP2, two brands of mobo, Matrox dual-head card, twin BFG GForce Nvidia FX5200oc 256 cards, three or four versions each of OpenGL and DirectX, more memory, faster Athlon CPUs, yet more memory, an AMD64 etc etc...
Nothing I did would 'enable' FP HA...
About the only thing in common was my fondness for AMD processors...
D'uh...
I have another product from the group, called Turbosketch. It is a render plug-in for Sketchup and has some fair promise. There is also a lack of solid info there, which leads me to suppose it is just the same old IMSI story of customers being treated akin to mushrooms.
I have been running a high quality render since yesterday and the 'counter' runs in seconds. Nice touch?
According to my math 93,636 seconds is aproximately 26 hours. Currently 87% rendered. Some kind of record?
Mike, is there a HA option in TurboSketch ??
And, uh, does it work ??
Nik, No, No, actually it does work but it is taking a lot of figuring out. Quick renders are quite reasonable tho' and can be done quite quick while (as above) the top rated studio render takes a 'bit' longer.
In my defence I have a 3ghz pc, a 256mg graphic card (Nvidia6800) and the 5gig of ram so it should be quite fast.
The render here is a low light render (No, really Sherlock?) which only took a few minutes to do, what do you think chaps?
(http://i147.photobucket.com/albums/r297/Mike1158/28dcolourenhancement.jpg)
Hi, I've done some hasty research on OpenGL versions...
Okay, the latest release seems to be 2.1, but Steve's 3.0 may be in BETA...
My CAD_PC gave 2.0=100%, 2.1=66%, based on a suite of checks...
Here's the free OpenGL benchmark and reporting software I found.
Usual cautions apply: Set a System Restore point before mucking with whatsits. Use due care, due diligence, virus-checker, pop-up killer, cookie cruncher etc etc. If benchmark requires you to close all other applications, take your modem off-line before stopping the fire-wall, restart the firewall before the modem etc etc...
Realtech-VR have both 32 and 64 bit reporters which check your OpenGL's driver version and 'entry points' against internal database. The 32bit software installed and ran okay on my stand-alone CAD_PC, but did not notice twin graphics cards and dual displays. The test crashed this modest Browser_PC. I've e-mailed Realtech about both issues...
http://www.realtech-vr.com/glview/
OpenBench ran okay on both PCs. Takes 5~~10 mins, juggles six white then rendered spheres in a window or full-screen at different settings. I felt rather sad watching this Browser_PC struggle while the CAD_PC flew. I don't begin to understand the reams of statistics, beyond this Browser_PC being OpenGL 1.x at best. The same Open Bench (100k) is available on several sites, but some require registration.
http://www.softpedia.com/progDownload/OpenGL-Geometry-Benchmark-Download-767.html
I found but did not dare try the 'hairy donut'...
http://www.ozone3d.net/products.php#gpu_benchmarking
Hope these help !!
Now I'm off to find some new drivers for this Browser_PC...
SD wrote...
Thank you.
OpenGL under Windows is not supporting multiple video card (only DirectX does it).
The errors found in reported are just extensions that nVidia removed in later drivers (yes, they don't add extensions, they remove them).
OpenGL 2.1 is not supported with your video card (Geforce 6 doesn't, not the Geforce 5 (or FX)). It's a hardware limitation.
I will check the clipboard data issue for the next version.
The crash is probably a display driver (probably your budget pc is only supporting DirectX, not OpenGL).
For your application, try to use the GLIntercept program. It's a rookit that replace OpenGL32.DLL and extract all the OpenGL code. So you will see what's happening (if it is really using hardware acceleration of not).
---
On 20-Oct-07, at 6:55 PM, Nik wrote:
> Hi, I ran your OpenGL Extensions Viewer 231 build 224 on my stand- alone dual-head CAD_PC, was unable to check the second screen's graphics card, or identify which card it was testing...
>
> That system is running XP_SP2, has 3Gb RAM, an AMD64 3700+ (=2G2) in 32bit mode and a matched pair of BFG AGP & PCI NVidia Gforce 5200FX (oc) 256 Mb cards which, happily, use an identical driver release...
>
> OpenGL cheerfully reported as 2.0 =100%, but 2.1=66%, with a bunch of entry-points missing or different names, per attached.
>
> FWIW, your 'clipboard' data does not format correctly in Notepad, but traditional swipe-select /copy /paste is okay...
>
> Sadly, running the tests on this budget BrowserPC crashed the program !!
> ---
>
> I'm working with other IMSI TurboFloorPlan forum members to establish why the new TFP v12, with all-new CAD-Soft core-code, cannot support Hardware Acceleration during rendering. We're told our OpenGL version is at fault, but our PCs easily exceed the box specs.
>
> D'uh, you would expect *some* users to have a compatible PC...
>
> Regards,
> Nik
> <OGLEV_LHS_txt.txt>
Mike,
I think the image has come out well. I am afraid I lost it a bit in this thread - was this a TurboSketch render or TurboFloorplan? Also, were you serious with your earlier comment about the 87% completed render at 26hours? Is that with TurboSketch? If it is, I think somehow the meaning of Turbo must be changing! It presumably should be a 'superdooper' render - hopefully you will give us a look - if it turns out OK.
Allan
Quote from: Mike1158 on October 20, 2007, 01:59:59 PM
The render here is a low light render (No, really Sherlock?) which only took a few minutes to do, what do you think chaps?
(http://i147.photobucket.com/albums/r297/Mike1158/28dcolourenhancement.jpg)
Hi Alan,
Yes, very serious about the render time (Tubosketch) and it actually completed in a staggering 32.475 hours. The previous image was adjusted by Irfanview via gamma correction. The Loooooooooooong render is below. Worth the hours? I think not myself but I may be byassed. Sorry, punny day today.
(http://i147.photobucket.com/albums/r297/Mike1158/29Studioqualityand116910seconds-1.jpg)
Er, Wow !!
( I've issues with that over-hang and un-guarded stair corner, but I've a low pain-threshold... ;-)
Hi Nick,
The whole idea behind the project is a small footprint. 25 feet wide by 35 feet deep and essentially open plan on the ground floor. One bedroom only with en-suite bathroom and a feeling of space as the core ethos. The design has similarities to cottages/early terrace homes where you go straight into the living space from the front door with no hallway. Curious in many respects because we would probably not think of doing things this way now.
Mike,
Well I would say the image is better, appears to have an extra light upstairs, but whether it is 33 hours better I am not sure. I certainly won't complain about FloorPlan render times any more! I used to think that overnight renders for V8 was bad but maybe THAT was Turbo after all!
Allan
Alan,
the first render was darkened via Irfanview. I am looking to produce an interactive childs book and some scenes need to be darkened. There is a candle on the extreme left of the picture which utilises a very handy feature of Turbosketch, glow. You can create a glow within any feature pretty much and with a light souce within the 'flame' you get what I think is a fair candle flame. Smokeless too.
Dave,
Is there a recommended video card for use with TurboFloorplan,
or better, which card is most widely used by the product developers?
Sebastian
Quote from: dtaylor on October 19, 2007, 01:09:38 PM
Minimum System Requirements
Microsoft
Here are responses on Open GL , Hardware Acceleration and Rendering from the developers contacts I have made.
Open GL
Implementation is based on the OpenGL 1.1 spec
Thanks, Jack !!
All I can suggest is that the TFP team contrive a tiny test-program aka 'HA_101' that calls all their expected OpenGL 1.0 entry-points, recovers from and reports errors...
TFP Forum members run it, render a supplied mini-plan and report findings.
Then we go around the loop again with 'HA_102' etc etc and 'home in' on the problem(s)...
Um, is there a C+ or JavaScripter in the house ??
My system far exceeds the min. requirements and is 100% OpenGL thru ver. 1.4 (including 100% for all versions less than 1.4) and I have the latest drivers (except for the last one which turns the drivers management control window 90 degrees for certain systems; not needed for mine)
But renders and render resets do NOT work well with OpenGL....mouse cursor hangs and flickers.....and renders are always washed out. Non-render OpenGL seems to work OK and is much faster than with HA off.
S/W render (HA off) reset/re-renders are not predictable....which is not seemingly an OpenGL issue but a different bug.
Conclusion: TFP renders have some bugs....also see latest render problem report confirmed today that sun thru open door renders incorrectly depending on camera positon...inside vs. outside vs. re-use radisosity.
I'd happily run a test render setup to help de-bug TFP because OpenGL is much faster on all my other graphics apps and they all run just fine...even one that has an OpenGL ver. 2.2 requirement.
I am not a gamer; this PC setup for intensive business graphics.
Doug.S
Quote from: dtaylor on October 19, 2007, 01:09:38 PM
Minimum System Requirements
Microsoft
Quote from: Doug.S on October 24, 2007, 12:47:40 PM
My system far exceeds the min. requirements (all/every) and is 100% OpenGL thru ver. 1.4 (including 100% for all versions less than 1.4) and I have the latest drivers (except for the last one which turns the drivers management control window 90 degrees for certain systems; not needed for mine)
But renders and render resets do NOT work well with OpenGL....mouse cursor hangs and flickers.....and renders are always washed out. Non-render OpenGL seems to work OK and is much faster than with HA off.
S/W render (HA off) reset/re-renders are not predictable....which is not seemingly an OpenGL issue but a different bug.
Conclusion: TFP renders have some bugs....also see latest render problem report confirmed today that sun thru open door renders incorrectly depending on camera positon...inside vs. outside vs. re-use radisosity.
I'd happily run a test render setup to help de-bug TFP because OpenGL is much faster on all my other graphics apps and they all run just fine...even one that has an OpenGL ver. 2.2 requirement.
I am not a gamer; this PC setup for intensive business graphics.
Doug.S
Quote from: dtaylor on October 19, 2007, 01:09:38 PM
Minimum System Requirements
Microsoft
As I understand it, the program 'knows' if it is inside a room or outside a building.
When 'inside' , to speed up the rendering process it 'ignores' the buildings 'outside'. So if you start a rendering inside and modify your viewpoint to outside, it will be dark. You should render outside if you want to view from the outside.
As far as the 'white washout' is concerned, I do not get that and I have no problem either modifying viewpoints or resetting radiosity.
Radiosity requires a lower brightness settings some times. In addition I lower the lights wattage. If you have created a 'new' light and not properly assigned the wattage it could be reverting to a default which could cause the problem
The only way to check all of this is to post a small file that shows the problem. I could forward it to those who know better.
Jack,
Thanks for the input on that. Unfortunately however I do still have some issues and, from the other posts you may have seen ,Doug and others are having similar issues. The render you attached by the way is very nice. I would be interested to see however, if you have some of the issues also by making some adjustments to it. To test this out try (1) changing the window that is letting the sunlight in at the lower left to a door and see if the light still comes in - I suspect it won't. (2) Place something outside the small window and see if it is drastically overexposed. The existing window appears to only show sky and the reflection of the inside. The background image never seems to be over or underexposed, it is always the same, but if you have anything outside the window (tree etc) it will be overexposed. (3) Add a room so that you can see the outside wall through this small window - is it black even though it is in the sun?
The attached image demonstrates these issues:
1. No sun comes in through openings that are not glass.
2. The sky, or any background image, is not reflected in the floor although other outside objects are.
3. Ouside walls are black when viewed from inside (or if you move the camera outside - see image 2 also)
4. Photoboards reverse the black wall effect where they cast a 'shadow' on the wall - sun goes through the transparent part of the photoboard. (see the 'outside view' of the same radiosity render as the larger image - photoboard effect very obvious)
5. Photoboards also reverse the 'no sun through glassless openings', allowing sun through their transparent parts only but still no sun through the rest of the opening.
6. All of these effects are reversed if the image is rendered first on the outside of the building and then the camera moved inside for subsequent raytraces.
Subsequent renders are all washed out unless I close the program completely and re-open.
Raytrace only renders work correctly - but far inferior quality of course.
Allan
I just don't understand Allan.
These tests show that rooms rendered first outside and then inside, that sunlight is correct, no overexposure at minus 1.5
I have added interior lights as they would be required to get the interior lit. Maybe they affect the overall brightness too.
All I can say is that there appears to be a great variation based on video cards but that is just a guess.
This set up is similar to yours Allan except I'm using white siding.
minus 1.5 Exterior first , interior second.
i think you guys can now trade *.bld files on the forum...if that would help.
:o
Dave,
Thanks for increasing the file attachment size as this will make trading files possible. However it should not be needed this case as mine is just 4 walls (6 now as it is L shaped to show the outside through the window) and all default settings are used. Jack's copy of mine looks the same and would be the equivelent for testing. Mine is also siding (default first wall in the list) but I did change the outside to brick on that one wall, as the siding showed up as bright white where the sun goes through the photoboard, but with the brick you can see it is brick. Likewise the doors can be just any door that is open.
Jack,
I get the same as you if I render from outside first as you apparently have done (that is my workaround) Try doing it from INSIDE first. This is when I find the sun does not go through the openings and the outside walls are black. I have not used any inside lighting - the purpose of the original test was just to see the effect of sunlight through windows and doors and how it was reflected around the room, as I use this in my modelling work. That was when I discovered the problem with sun through doors and black outside walls.
Try using the same file as above but render from INSIDE first. I had also attached my file just in case your does work OK - then you can see if mine does on your PC.
Also I have just got my desktop back after it had a hissy fit (RAM failed!) so I will try it there also and let you know the results (It has Nvidia graphics card). Incidentally for some reason I cannot open your image or save it - says IE does not recognise it. However I can see from the thumbnail that it is OK (from outside - as mine is). Try rendering inside first - if that is OK then it must be a PC specific problem.
Allan
Hi Allan,
You can't get light through an opening without first rendering from the outside (of course , I know how to cheat :-)
The dark wall is from the minus 2.5 setting . Try -.25 or less, if you don't have any interior lights.
As a general statement Radiosity shouldn't be used for exterior renderings as it requires something to bounce the light around for calculations, not much to bounce off of outside. But I am working on settings to get exteror results as I do like them better.
I believe the openings are not the same as doors / windows. I think they use an invisible wall , similar to room divisions. If you use a room division , say in a kitchen with a light and place your camera say in the living room away from the room division, when you render the 'invisible wall' created by the room division will not let the light from the kitchen be present. That is why I don't use room division, I use floor/ceilings by pick point to define new surfaces.
So, if this is the case then the invisible wall on the outside lets light show through when you are outside but not when you are inside.
Try this cheat (trick, work a round, out of the box) solution.
Theory is that openings only let light in when rendered from the outside.
So, render from the inside but use an 'outside view'.
The way to do that is to fool the program into thinking you are outside when you are actually inside.
To do this you must not have an enclosed space. So, put a 'break' in one wall (you will lose the floor so add it by pickpoints), and seperate the broken wall just a touch. All your exterior walls will convert to interior walls and require resetting of materials / removal of baseboard if you see them through a window/ door / opening.
Now render with your camera inside as normal using Radiosity.
The edited attachment was 'brightened' in a photo editor.
Let me know if you want the adjusted file.
Z
ps. when a door or window is in the wall the 'glass' takes the place of the 'invisible wall' and creates full sun, when the door is 'open' the 'invisible wall' takes over and the results are the same as an opening.
It would seem if they could use 'clear glass' instead of an 'invisbile wall' they could solve the problem. But I'm sure they have tried that. I 'll write to them on Monday.
Jack,
So I take it that you are confirming what I found, that light will not go through doors and openings when rendered from inside but rendering from outside first is a workaround.
I still have the black wall problem. It is not because I rendered before at -2.5. The examples below were rendered at +2 and the walls are still black (the siding and the brick), even though everything else outside is totally overexposed. The sun does not shine on the walls (except through the transparency of the photoboards).
Breaking the walls to fool the program seems to create a lot of complexity, although it obviously works. The two lower images were rendered outside first, with three ceiling lights inside to brighten it. Brightness was 0. With better placed interior lights it should be quite acceptable. Increasing the interior lights wattage also increases the exterior light and it starts to overexpose but as long as you do not go too far it is reasonable. (single image)
I notice that your images also do not show the reflection of the sky in the floor. I will try a large photoboard background when I get time as I suspect that will work to provide the reflection when needed.
I suspect there are a number of issues here to pass on - at least they all have workarounds.
Allan
I don't think it is a workaround, I think it is as designed. But yes the sun will not come through 'openings' when rendering from the inside, you must 'cheat' or do outside rendering first.
The reason for the dark walls is most likely the same issue, they have made the program render faster by ignoring some of the exterior lighting when inside.
I have used photo boards before and they do reflect from the outside into windows, I have not tried them for floors.
Jack