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.

AppGameKit Classic Chat / Normals and edging cubes

Author
Message
nz0
AGK Developer
17
Years of Service
User Offline
Joined: 13th Jun 2007
Location: Cheshire,UK
Posted: 15th Mar 2017 23:53
Link
So I have been trying to flat shade this model.

It is made of independent cubes which look fine in Lightwave but show the individual blocks in AppGameKit due to the normals, even though the non-facing parts of the cubes shouldn't be visible.

If I don't light the objects I don't get the seams, but that is not what I want. I want the faces to be seamless and accept lighting.

I've not been able to fiddle a way with using hard or soft normals or anything else. I tried using a light map, but that doesn't work either.
My Robotron remake
My I,Robot remake WIP
My Defender remake

Attachments

Login to view attachments
Back to top
Profile PM Email Website
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 16th Mar 2017 09:06
Link
maybe you can use a script in Lightwave , if 2 faces have his 4 points at the same place and the sum of booth normals are ~ 0 you can remove this 2 faces.
other idea, give the face-to-face a transparent color.
if you zoom in to this model in Lightwave there are no gaps between cubes?
AGK (Steam) V2017.02.28 : Windows 10 Pro 64 Bit : AMD (17.2.1) Radeon R7 265 : Mac mini OS Sierra (10.12.2)
Back to top
Profile PM Email
Mobiius
Valued Member
21
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 16th Mar 2017 09:11 Edited at: 16th Mar 2017 09:12
Link
I believe you'd need to fix the UV coordinates in lightwave, as currently each cube is UV mapped individually, but you really need to whole object mapped as a single object.
Also try to scale each cube up very slightly. (For example, if eack cube is 1x1x1 units, scale it up to 1.01x1.01x1.01. The slight overlap may help with the seams since on closer look, it's not a lighting seam you're getting.)
Signature removed by mod because it's larger than 600x120... please resize and try again.
Back to top
Profile PM Email Website
Van B
Moderator
22
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 16th Mar 2017 14:16
Link
I think you'd have to combine it all into 1 object, so the adjoining sides of the cubes can be welded - also the caulked faces could be removed, and probably help get rid of the grid lines you're seeing. I'm sure it will be the internal faces that are causing the grid lines, as really they should be drawn - if you know what I mean - the 'hidden' faces have an edge that is equal to the edge on the visible polygon, so the edge piece is visible, the only way to be sure to get rid of the edge line is to get rid of what's causing it.
The code is dark and full of errors
Back to top
Profile PM Email
nz0
AGK Developer
17
Years of Service
User Offline
Joined: 13th Jun 2007
Location: Cheshire,UK
Posted: 16th Mar 2017 18:12
Link
Quote: "I believe you'd need to fix the UV coordinates in lightwave, as currently each cube is UV mapped individually, but you really need to whole object mapped as a single object.
Also try to scale each cube up very slightly. (For example, if eack cube is 1x1x1 units, scale it up to 1.01x1.01x1.01. The slight overlap may help with the seams since on closer look, it's not a lighting seam you're getting.)
"

I tried the scale up approach, which had a slightly positive effect, but it didn't work 100%. I also tried scaling up the UV which also doesn't work.

Quote: "I think you'd have to combine it all into 1 object, so the adjoining sides of the cubes can be welded - also the caulked faces could be removed, and probably help get rid of the grid lines you're seeing. I'm sure it will be the internal faces that are causing the grid lines, as really they should be drawn - if you know what I mean - the 'hidden' faces have an edge that is equal to the edge on the visible polygon, so the edge piece is visible, the only way to be sure to get rid of the edge line is to get rid of what's causing it.
"

I feared as much. I know this would work, but it's a lot of extra effort as I wanted the individual cubes (I was even going to subdivide it when it gets blown up)
Yes, I think that the lines are the zero sized edges of the invisible faces of the cube and I think I've run into this problem before with AppGameKit (virtually everything else I load the model up in looks seamless).

Quote: "maybe you can use a script in Lightwave , if 2 faces have his 4 points at the same place and the sum of booth normals are ~ 0 you can remove this 2 faces.
other idea, give the face-to-face a transparent color.
if you zoom in to this model in Lightwave there are no gaps between cubes?
"


I'm not sure I can do that in layout - only on individual meshes - besides, I'm no good at LW scripting
Zooming in on LW is perfect joins - in fact, I hand typed the co-ords to make sure they were perfectly aligned.

One other possibility is to post process the cubes in AppGameKit and mess with the faces, but I fear the mesh manipulation functions are not sufficient.

Thanks for the feedback anyway... I'll try a few more things...
My Robotron remake
My I,Robot remake WIP
My Defender remake
Back to top
Profile PM Email Website
Paul Johnston
TGC Developer
22
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 17th Mar 2017 16:59
Link
First thing that comes to mind is it might be the depth buffer, if you zoom in very close in AppGameKit do the joins disappear?
Back to top
Profile PM Email
nz0
AGK Developer
17
Years of Service
User Offline
Joined: 13th Jun 2007
Location: Cheshire,UK
Posted: 17th Mar 2017 23:21
Link
Hi Paul,

Not totally disappear, but does improve.

When I described the problem to a friend, they suggested looking at the z buffer. I might have one final play with that, but I have now remade the model as "standard" geometry and it looks perfect now. Subsequently, I will need to calculate an array of smaller cubes now which I could generate / assign at the point where I want to disintegrate the character which may be better in the long run?
It is interesting that most other 3d viewers / editors don't show the poly edges though.
My Robotron remake
My I,Robot remake WIP
My Defender remake
Back to top
Profile PM Email Website
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 17th Mar 2017 23:42
Link
Have you tried one of the shaders? maybe a cartoon shader
https://forum.thegamecreators.com/thread/214598
Back to top
Profile PM
nz0
AGK Developer
17
Years of Service
User Offline
Joined: 13th Jun 2007
Location: Cheshire,UK
Posted: 18th Mar 2017 01:50
Link
I thought about that and I did try using a couple of shaders, but I wasn't sure what the actual problem was.
I think the shader would also have to know what the problem was as well.
My Robotron remake
My I,Robot remake WIP
My Defender remake
Back to top
Profile PM Email Website
Paul Johnston
TGC Developer
22
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 20th Mar 2017 14:22
Link
Quote: "Not totally disappear, but does improve."

That would suggest it is the depth buffer. In which case there is much you can do. The ideal solution would be to increase the depth buffer precision, but some mobile devices only have 16bits of depth and everything else uses 24bits, so we're already at the limit of what OpenGL 2.0 can do. You could try moving the near plane closer to the model by using SetCameraRange, which will put more of the depth buffer accuracy nearer the model, but when the camera moves away you're going to have the same problem.

A shader might be able to help, the only thing I can think of is marking the faces that are hidden by another cube with something the shader can detect, perhaps a UV coordinate in a particular range, and using the "discard" command to stop that pixel drawing.
Back to top
Profile PM Email
Preben
AGK Studio Developer
20
Years of Service
User Offline
Joined: 30th Jun 2004
Location:
Posted: 20th Mar 2017 14:42 Edited at: 20th Mar 2017 14:46
Link
Did you try vertex light ?, if your using per pixel light the normals will be interpolated and could generate a pattern like this , if you use vertex light each side of the cube would use the same normal , and should give you the same light ( no borders ).

If that dont work, check if your cube 'only" have 1 normal per side, it should only use one normal per side.
best regards Preben Eriksen,
Back to top
Profile PM Email
nz0
AGK Developer
17
Years of Service
User Offline
Joined: 13th Jun 2007
Location: Cheshire,UK
Posted: 20th Mar 2017 19:30
Link
Quote: "That would suggest it is the depth buffer. In which case there is much you can do. The ideal solution would be to increase the depth buffer precision, but some mobile devices only have 16bits of depth and everything else uses 24bits, so we're already at the limit of what OpenGL 2.0 can do. You could try moving the near plane closer to the model by using SetCameraRange, which will put more of the depth buffer accuracy nearer the model, but when the camera moves away you're going to have the same problem.

A shader might be able to help, the only thing I can think of is marking the faces that are hidden by another cube with something the shader can detect, perhaps a UV coordinate in a particular range, and using the "discard" command to stop that pixel drawing.
"


I think I will be making life difficult for myself further down the road (multiple objects would eventually be in use at different ranges).
I reckon you are right about a shader discarding certain faces, but I've since got around it by using a properly textured model and switching to the cubed version at the destruction mode.

Quote: " Did you try vertex light ?, if your using per pixel light the normals will be interpolated and could generate a pattern like this , if you use vertex light each side of the cube would use the same normal , and should give you the same light ( no borders ).
If that dont work, check if your cube 'only" have 1 normal per side, it should only use one normal per side.
"


Yea, I has all that set up at first and still showed the effect.
My Robotron remake
My I,Robot remake WIP
My Defender remake
Back to top
Profile PM Email Website
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 20th Mar 2017 21:07
Link
I don't know if this helps be the .x format is a very readable format. maybe you could pre-process the model
Back to top
Profile PM
nz0
AGK Developer
17
Years of Service
User Offline
Joined: 13th Jun 2007
Location: Cheshire,UK
Posted: 20th Mar 2017 23:16 Edited at: 20th Mar 2017 23:17
Link
I'm using .x now anyway for the animated model.
It's not that great a problem to create an array of cubes for the destruction modes.

Here's an example of where I've got up to.
My Robotron remake
My I,Robot remake WIP
My Defender remake
Back to top
Profile PM Email Website
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 20th Mar 2017 23:18
Link
Haha. It looks great. Good luck with your efforts
Back to top
Profile PM
nz0
AGK Developer
17
Years of Service
User Offline
Joined: 13th Jun 2007
Location: Cheshire,UK
Posted: 20th Mar 2017 23:22
Link
Part of my concerns were when I found that most other render engines don't show the edges on this sort of arrangement.
Also, there's a problem with vector drawing (2 point poly) in the AppGameKit engine which shows up from external modelling packages as well. This is demonstrated by the missing 3DPhysics debug functions which is desperately required.
My Robotron remake
My I,Robot remake WIP
My Defender remake
Back to top
Profile PM Email Website
Back to top

Login to post a reply

Server time is: 2024-11-24 18:27:31
Your offset time is: 2024-11-24 18:27:31