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 Studio Chat / What changed when it comes to the UV handling or texturing of primitive box objects? My textures are all messed up now in AGK Studio, but fine in AGK2

Author
Message
PHeMoX
1
Years of Service
User Offline
Joined: 9th Jan 2018
Location:
Posted: 12th Aug 2019 18:26
I'm using some code so I can use a single texture for all my 3D tile surfaces to create a level with. For some odd reason it stopped working now.

Did any of these commands change in AppGameKit Studio compared to AppGameKit 2 ???

SetObjectMeshUVScale( )
SetObjectMeshUVOffset( )

I'm using a version of the code that allows us to change textures or add texture animations to 3D objects. In this case it's really just a level generator that changes the texture once.

For some weird reason it now doesn't calculate the correct texture anymore, including height and width. The texture is 340 pixels by 384 pixels. And works fine in AGK2.

I guess it's being rendered differently now?? Or any other things that affect the UV mapping now?


the yellow comes from yellow pixels being basically the last tile, you can see the texture used in the AppGameKit Studio view.

Exact same code, but ran in AGK2 :






Attachments

Login to view attachments
PHeMoX
1
Years of Service
User Offline
Joined: 9th Jan 2018
Location:
Posted: 12th Aug 2019 18:51 Edited at: 12th Aug 2019 19:14
I am guessing it is Vulcan related?? edit: Or maybe not, #renderer "Basic" doesn't change anything. Because the code still works fine when broadcasting the code to Android device:

Attachments

Login to view attachments
SFSW
16
Years of Service
User Offline
Joined: 9th Oct 2002
Location:
Posted: 12th Aug 2019 21:32
Short answer is yes, UV has changed, but more corrected rather than merely altered. Previously, the UV offset state didn't seem to correlate properly with scale. That is, AppGameKit would apply the offset first before handling the scale. It should have been applying the scale first, then the offset. So if you scaled to a particular level and then offset, you'd shift by offset initially rather than account for the scaling first. So in your code, you'll just need to account for this corrected formatting and adjust your offsetting accordingly (you don't need to change your scaling factors). There may also be differences in the default uv wrap setup, but I haven't tested that much yet as I typically specify my own anyway at the beginning of my projects. So that might just be something else to double check:

SetDefaultWrapU(1)
SetDefaultWrapV(1)

But for now when it comes to offsetting, you will need to use your original approach when outputting to Android as that uses the older render path with the older (incorrect) UV offsetting. Then have a variable for a mode switch to compile for the other desktop options as may be needed when building/testing for different platforms. One of the reasons for my request of a 'GetRenderMode' option was to account for differences like this where if a variation was required in either the Andoird-GL, OpenGL, or Vulkan render path, we could detect it and account for it as needed in code with a simple 'if/endif' block. This would also lets us specify shaders, parameters, and anything else that need to be different between different rendering paths. So I'm still hopeful that such an option will be available that better accounts for differences that may be required between rendering options. There are some parameter specific checks you can use currently, but nothing yet as global as would be needed.
blink0k
AGK Developer
Gold Codemaster
6
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 12th Aug 2019 23:04 Edited at: 12th Aug 2019 23:24
From Paul Johnson
"This is due to a UV offset change, previously the offset would get scaled by the UV scale amount, but in the new AppGameKit the UV offset does not get changed by the scale. I think it makes more sense that way. In this project changing these two lines would fix it
inc io, 0.25
if io > 0.75"

In my case i think i had used
inc io,1
if io >3

To iterate through 4 images

So basically now i think it's always a value between 0 and 1. As far as i can see the new approach works for "Basic" renderer as well.
PHeMoX
1
Years of Service
User Offline
Joined: 9th Jan 2018
Location:
Posted: 13th Aug 2019 00:39 Edited at: 13th Aug 2019 00:42
Yikes. I don't think it's very good that we now have to deal with two render paths at all.

Isn't there a way where the same code would result in the proper texturing? Maybe the order of code? I've tried changing the offset before setting the scale, but it doesn't change anything. It almost seems like the particular texture trick won't work in AppGameKit Studio. Maybe I'm missing something here when it comes to your explanation.

edit: Thanks blink0k . From the sound of it, I have to change the offset values then. Hmm. Sounds like I have to change a lot of code for that then.
SFSW
16
Years of Service
User Offline
Joined: 9th Oct 2002
Location:
Posted: 13th Aug 2019 00:47 Edited at: 13th Aug 2019 00:48
PHeMoX wrote: "Yikes. I don't think it's very good that we now have to deal with two render paths at all."


When it comes to UV scaling and offsetting, I'm hopeful that won't always be the case. Eventually, the OpenGL render paths should be aligned with the new Vulkan format.

PHeMoX wrote: " Isn't there a way where the same code would result in the proper texturing? Maybe the order of code? I've tried changing the offset before setting the scale, but it doesn't change anything. It almost seems like the particular texture trick won't work in AppGameKit Studio. Maybe I'm missing something here when it comes to your explanation. "


For now, you will need to separate the two, but they should all eventually be aligned with the corrected Vulkan render path. Just keep your code adjustable with value checks so it can quickly change and adapt as needed when/if things changed in future updates.

And lastly, you simply need to change the offsetting -values-, not the order of scaling vs offsetting (that's only how AGKS now handles things internally to explain the difference in behavior). If you change the scaling at all, then you need to change your offsetting to accommodate a 1:1 baseline. It's actually a little easier to manage things that way as well.

Login to post a reply

Server time is: 2019-08-26 04:48:42
Your offset time is: 2019-08-26 04:48:42