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.

3 Dimensional Chat / Graphics look bad where they overlap

Author
Message
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 6th May 2003 14:37
I have some graphics where 2 sections overlap, and this causes a horrible effect in DB. The overlap edge looks wavy, or serated. When the object moves, this wavy edge takes on a life of it's own.

Is there any tool in a 3D modelling app that will allow me to remove the hidden faces that are causing this. I use Wings 3D and Cinema 4D.

I have also found other weird problems such as a tree trunk that should be hidden by the solid tree foliage shows through. Am I doing something wrong?
Thanks in advance.
All the Best,
StevieVee
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 6th May 2003 14:54
Well, not really your fault it's a problem with the camera clipping range, and is a problem in a lot of other DX engines.

Try setting your camera range forward a little, like if your camera range is 1 to 1000 already, try making it 5 to 1000.


Van-B
actarus
21
Years of Service
User Offline
Joined: 29th Aug 2002
Location: 32 Light Years away
Posted: 6th May 2003 15:50
Yeah really overlapping is no 3d'er's friend so keep away from it and go for a 'flush' positionning.

Caught by the Fuzz,well I was,still on my buzz
In the back of the Van,with my,head in my hands
Shadow Robert
21
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 6th May 2003 18:49
alternatively you can turn off the ZBuffer and posting the objects in the order you wish them to be seen in. can cause cool if you do it with a level and don't repostion everything, you don't have to move it, just reposition to where it is in the order from back->front based on the camera's depth - crude but efficient

Tsu'va Oni Ni Jyuuko Fiori Sei Tau!
One block follows the suit ... the whole suit of blocks is the path ... what have you found?
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 6th May 2003 19:19
Cheers, guys, I'll try out your suggestions.

The Z Ordering is probably too complex, the camera is following multiple objects at different distances, and flying from one to another. Sometimes it's looking back, other times forwards. And my Maths is pants.

I will definitely try and reduce my models to have no overlaps - I just need to work out the way it's done in either Wings 3D or Cinema 4D.

Camera Clipping - that's easy to try, I'll be checking that one out first.

Thanks in advance.
All the Best,
StevieVee
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 7th May 2003 04:11
Camera Clipping works! Fantastic!

I don't understand why, perhaps someone can enlighten me. It also gets rid of some horrible black bands that kept appearing on my textures. My camera clipping started at 1, I changed it to 5 and it solved both issues.

I thought camera clipping was simply about the distance from the camera that rendering started and ended?

Thanks in advance.
All the Best,
StevieVee
Andy Igoe
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: United Kingdom
Posted: 7th May 2003 06:41
I read up on 3D engine rendering problems when I first encountered this issue (and also the gimbal lock issue) in DB and to my understanding:

Distance calculations in DBPro are done 'the fast way' which is not necessarily the accurate way. Making this configurable would add a decision path in the rendering engine that is called too many times during a screen refresh to be efficient for speed and so only one method can be employed in the engine.

We then have to work around the short-comings of this fast maths by adding polygons to our objects and thus loose all the speed gained from the faster calculation in the first place... ho hum.

Pneumatic Dryll
Shadow Robert
21
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 7th May 2003 14:05
nothing to do with adding polygons the problem will still occur, the fact of the matter is the the Zbuffer in DarkBasic is setup for a very specific range and the only way to change that is to setup the camera range which is the rendering buffer that DirectX uses.

effectively rather than setting up the zbuffer again you're setting up the camera again - this has nothing to do with what DarkBasic Software have programmed as they're using the built in DirectX ZBuffer - the new WBuffer actually solves alot of the Zbuffers problems because the focus just isn't deep enough when your scenes are too small or too large.

the best way to stop it happening is to actually develop world with a 1:1 ratio to dbu

Tsu'va Oni Ni Jyuuko Fiori Sei Tau!
One block follows the suit ... the whole suit of blocks is the path ... what have you found?
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 7th May 2003 14:13
Would moving the vertices by a tiny tiny amount fix it? - like if no polygons are in contact on their surfaces?. I mean moving the level objects by a random amount is not a huge coding task, and would not be noticable if the adjustments were small enough.


Van-B
Andy Igoe
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: United Kingdom
Posted: 7th May 2003 15:44
Quote: "nothing to do with adding polygons the problem will still occur"


Not what I meant. Picture a roadside billboard advert (not a 3D engine billboard) with it's big square advert area and two legs to stand on.

Viewing from behind you might get the big square area showing through the posts so to get around that my method is typically to break the big square area down so I can delete the areas of the face that are behind the legs at least for the rearward direction.

This was what was being discussed. And such ammendments clearly add extra polygons to the model in this case that would be 3 polygons post-optimisation, thus creating the speed enigma I was trying to describe.

Pneumatic Dryll

Login to post a reply

Server time is: 2024-05-06 17:07:06
Your offset time is: 2024-05-06 17:07:06