Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Bug Reports / [u7.4] Culling and Object In Screen

Author
Message
Math89
20
Years of Service
User Offline
Joined: 23rd Jan 2004
Location: UK
Posted: 13th Jun 2009 13:24
This bug is still there since 6.7: the object in screen command often returns some false positives. Moreover, using offset limb gives worse results, even though the 'recalculate bounds' flag is set to one.

This code shows which objects are seen by the first camera. Press space to change the normal positioning code for the one using offset limb.
kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 14th Jun 2009 02:18
You'll have to make your own code. DBPro uses sphere culling.

New specs: Nvidia Geforce 9600GS 768MB, AMD Anthlon x64 X2 4000+ (2.6GHz Dual core), 3GB DDR2 800MHz RAM and a big hard drive.
Silverman
17
Years of Service
User Offline
Joined: 18th Jan 2007
Location: France
Posted: 14th Jun 2009 03:25 Edited at: 14th Jun 2009 03:26
There is another command : PERFORM CHECKLIST FOR ONSCREEN OBJECTS 0

This way is more accurate, but the bug is still there :



AMD Athlon(tm)XP 3200+ (2.2GHz) / DDR pc3200 (1024Mo) / Nvidia 6800GT (driver 178.24 WHQL)/ XP Pro SP3 / DirectX 9.0c (march 2008)/ DBPro 7.1
James H
17
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 14th Jun 2009 03:39 Edited at: 14th Jun 2009 03:55
kaedroho, is the method of sphere culling not ideal for a true in screen test or is it just dbp? I wouldn`t know but would like to know. The helpfiles clearly state how the in screen command should behave, which doesn`t tally with what we see. Either the help should be changed or the command fixed.
Math89, since 6.7 you say? Would that be based on existing bug reports or did you test each upgrade?(just wondering)
Also, about the test code;
One camera should be sufficient to high light the issue - its a screen test; multiple camera use should be used to prove that the bug is camera related, right now it just over-complicates the test.
The helpfiles state not to use limb zero.
Set current camera should not be needed as originally its a dark shader command iirc and the object inscreen command existed long before the upgrades that now include the set current camera command. I realise we are talking 7.4 here but as you say its a long standing issue. I did produce some code in another bug report someone put up which I think if altered to place the objects in it in a cube pattern instead of a grid, it shows that the inaccuracies occur where object positions are roughly in line with a plain/plane? that has the same rotation as the camera. I`ll post some code shortly. All of this my opinion of course, nothing concrete

Edit:


HOLD spacekey to pause in screen test whilst using wasd and mouse to move away from the "paused" scene to see the innacuracies as described
Math89
20
Years of Service
User Offline
Joined: 23rd Jan 2004
Location: UK
Posted: 14th Jun 2009 12:11
Whatever culling system dbpro uses, it shouldn't behave this way.
This code is actually based on my previous bug report which is marked as 'fixed' but is clearly not.
The Set Current Camera has always existed in DBPro, it is important to use it, because the Object In Screen command is based on the current camera.

What I don't understand is why the frustum culling and the OnScreeObjects give a different result than Object In Screen, shouldn't they be based on the same code?
James H
17
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 14th Jun 2009 15:05
Quote: "This code is actually based on my previous bug report which is marked as 'fixed' but is clearly not."
doh, how did I miss it was you who made the report!(btw its not marked as fixed but confirmed - 6.7 that is)
Quote: "The Set Current Camera has always existed in DBPro, it is important to use it, because the Object In Screen command is based on the current camera."
ah yes, my apologies, I was thinking of sync camera for some odd reason(I`ve actually used set current camera in conjunction with object inscreen before with multiple cameras succesfully bar the bug, I have a terrible memory!). Still only one cam needed to show the issue? - once fixed then maybe look at testing object limbs and other cams? Just thoughts once again. That said, if we are expected to use the checklist method instead of getting the original inscreen check fixed, does the other command need removing to avoid confusion? A fix would be better for the inscreen command as it already existed - new commands that still don`t work don`t improve the situation(*haven`t tested Silvermans code or looked into this yet* though glancing at the code limb zero should not be used), plus wouldn`t performing a checklist need to be done everytime there is a change to an objects or cameras position/rotation in the scene(once each frame)? If so would this not affect performance significantly? Versus the object in screen command I mean.
Quote: "shouldn't they be based on the same code?"
hmm, I would suggest no - the fact that new commands were created without the intended use of the original command suggests this. Otherwise the original command could have just been fixed. Guessing of course.
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 19th Jun 2009 20:34 Edited at: 19th Jun 2009 20:34
This is listed as fixed in 7.4b7 - can you confirm?

Also note that when you reposition limb 0 of an object, its bounds are not correctly fixed unless you also use SET OBJECT FRAME Obj, 0, 3. You'll need to include that line after the OFFSET LIMB command in your example code.

Math89
20
Years of Service
User Offline
Joined: 23rd Jan 2004
Location: UK
Posted: 20th Jun 2009 14:30
I confirm that my example works fine on the last upgrade.
kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 27th Jun 2009 16:05 Edited at: 27th Jun 2009 16:06
My example doesn't work. I'm using multiple cameras. This broke in the previous update which solved your program but made mine break.

As you can see, it only checks if the object is in camera 1 and not camera 0

upkey = move forward
mouse = look
enter = position camera 1 to camera 0s position




New specs: Nvidia Geforce 9600GS 768MB, AMD Anthlon x64 X2 4000+ (2.6GHz Dual core), 3GB DDR2 800MHz RAM and a big hard drive.
Math89
20
Years of Service
User Offline
Joined: 23rd Jan 2004
Location: UK
Posted: 27th Jun 2009 16:15
Maybe you should try using Set Current Camera to define which camera is used for the Object In Screen command.
kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 27th Jun 2009 20:11
which will really suck because a lot of people use multiple cameras in different places. For like reflection, etc.

IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 27th Jun 2009 23:46
I guess you're saying that it should always use camera 0 to detect visibility - What happens when someone actually wants to do that with another camera?

I think that using the SET CURRENT CAMERA command to determine which camera to use is a good compromise.

kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 28th Jun 2009 00:19
So your saying that TGC are not going to bother to solve this?

IT BROKE IN THE LATEST RELEASE!

Doesnt Lee want to know what 7.4 breaks?

Diggsey
18
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 28th Jun 2009 00:42
@kaedroho
Surely it is fixed... The camera commands are SUPPOSED to use the current camera for all their operations unless otherwise specified. Why is using 'set current camera' so difficult?

kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 28th Jun 2009 01:44 Edited at: 28th Jun 2009 01:47
I have many apps that rely on the command to check if its in any camera. I guess ill have to make my own frustum culling code.

BlitzTerrain for example. Only does LOD switches to sectors which are in the screen. I have users complaining that this isnt working.

Diggsey
18
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 28th Jun 2009 11:09
Or you could just loop through each camera

IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 28th Jun 2009 11:53
Quote: "I have many apps that rely on the command to check if its in any camera."

Really? In that case your code only ever worked by coincidence - the OBJECT IN SCREEN function has only ever used the current camera and has never checked against each and every camera.

Run the following code in 7.3 and you'll see that even though camera 0 is showing the object, the current camera is camera 1 and OBJECT IN SCREEN is NOT detecting the object.


The recent changes were only to increase the accuracy of detection - they haven't changed in any other way.

kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 28th Jun 2009 16:01 Edited at: 28th Jun 2009 16:02
Yes, it explains a lot of problems I've been having recently. And no, they never worked. I don't know what I should do. I use that command for all of BlitzTerrains frustum culling and I've been getting loads of complaints about the culling issues people are having with multiple cameras. I cant get DBPros Automatic frustum culling to work with it.

Quote: "Or you could just loop through each camera"


How?

IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 28th Jun 2009 16:38
Something like this:


The number of cameras is effectively unlimited, but 32 cameras should be more than enough for most people

kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 28th Jun 2009 21:30
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 28th Jun 2009 22:47
Oops, I forgot to mention that the CURRENT CAMERA function is one from my plug-ins. You can remove the call if you wish, but the current camera will be set to the last one detected when the function returns.

kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 28th Jun 2009 23:31
I have your plugins so its alright.

Is there any way I can get the current camera in a plugin?

Diggsey
18
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 29th Jun 2009 01:21
It is a member of GlobStruct, can't remember the exact name, something like iCurrentCamera. (I assume you know how to get the GlobStruct?)

kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 29th Jun 2009 03:55 Edited at: 29th Jun 2009 03:58
Yes I do. Ill have a look at it.


EDIT: I think its this one.

DWORD dwCurrentSetCameraID;

Diggsey
18
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 29th Jun 2009 23:01
kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 4th Aug 2009 02:38
http://forum.thegamecreators.com/?m=forum_view&t=145404&b=8&msg=1817979#m1817979

Other people are getting culling issues now .

I guess that I must make another demo showing the real problem.

The real problem occurs in Advanced Terrain aswell.

Login to post a reply

Server time is: 2024-05-12 05:31:40
Your offset time is: 2024-05-12 05:31:40