@pspeed said:
No. You misunderstand the interaction between Nifty and JME. Nifty says: draw this part of this image, draw this part of this image, draw this part of this image, etc... for each of those, JME sets the texture coordinates, sets the transform of the quad, renders the quad... over and over. Effectively this is like having x number of quads.
Yes! You must be misinterpreting me talking about object count in the post you quote, I guess. I gave an example for a possible low-level / self-built solution for that quite some time ago in this thread.
Nehon said: âIf they are different then they are updated. It cannot be otherwise.â
I said: âIf they are different then they are updated. It cannot be otherwise.â
Both of us were talking about how nifty interacts with JME.
âŚthen you said I was wrong. âBut they are only different when the layout changesâ
So I was correcting that. The texture coordinates change many times per frame. The same number as the number of partial images on the screen.
The low level solution is not to use nifty so that you can use a texture atlas since a texture atlas buys you nothing in nifty except some saved texture space maybe. Itâs unclear whether 49 separate small textures or one giant texture matters much in this case since they can all fit on the GPU.
Nehon said: âIf they are different then they are updated. It cannot be otherwise.â
I said: âIf they are different then they are updated. It cannot be otherwise.â
Both of us were talking about how nifty interacts with JME.
âŚthen you said I was wrong. âBut they are only different when the layout changesâ
So I was correcting that. The texture coordinates change many times per frame. The same number as the number of partial images on the screen.
The low level solution is not to use nifty so that you can use a texture atlas since a texture atlas buys you nothing in nifty except some saved texture space maybe. Itâs unclear whether 49 separate small textures or one giant texture matters much in this case since they can all fit on the GPU.
Right, the texture coords, I lost you three at the 8th detail of the nifty implementation.
Still you now misinterpret me talking about Nifty again in the âlow level solutionâ I mentioned, I talked about basically the same as you later did too, just with the extension of using an atlas instead of just jME Pictures. Nifty could just supply better id-ing for objects on screen that jME is supposed to draw to solve this âcoord update problemâ if it is one, I bet Jens wouldnât mind thinking about it. They wouldnât even have to be collected or anything beyond one frame.
Nehon said: âIf they are different then they are updated. It cannot be otherwise.â
I said: âIf they are different then they are updated. It cannot be otherwise.â
Both of us were talking about how nifty interacts with JME.
âŚthen you said I was wrong. âBut they are only different when the layout changesâ
So I was correcting that. The texture coordinates change many times per frame. The same number as the number of partial images on the screen.
The low level solution is not to use nifty so that you can use a texture atlas since a texture atlas buys you nothing in nifty except some saved texture space maybe. Itâs unclear whether 49 separate small textures or one giant texture matters much in this case since they can all fit on the GPU.
Right, the texture coords, I lost you three at the 8th detail of the nifty implementation.
Still you now misinterpret me talking about Nifty again in the âlow level solutionâ I mentioned, I talked about basically the same as you later did too, just with the extension of using an atlas instead of just jME Pictures. Nifty could just supply better id-ing for objects on screen that jME is supposed to draw to solve this âcoord update problemâ if it is one, I bet Jens wouldnât mind thinking about it. They wouldnât even have to be collected or anything beyond one frame.
Everyone in the conversation was talking specifically about the nifty implementation now since it was recommended by someone to try using it to do atlases instead of just using JME directly. I pointed out that the nifty implementation is non-optimal for this case. nehon said he fixed that issue. I said no, not really and that it was basically impossible (given the current nifty->JME implementation it is impossible). He agreed⌠then you start correcting me. Is it wrong that I would assume that you were talking about the same topic we were?
Bottom line:
an atlas is definitely the most optimal way to go.
nifty can technically do an âatlasâ but it provides no benefit over separate images.
fixing nifty to handle atlases well is on no oneâs to do list currently, requires changes (or some unknown level of impact) to nifty itself, and is a sizable change. ie: unlikely to happen in the near term. I agree that passing an ID or something means we could do something similar to the optimization done for bitmap text of the frame-coherent caching. I donât believe it will happen soon enough to matter to the OP. I guess we could also create a texture coordinate keyed cache without needing a change to nifty⌠but how far backwards do we bend to match up two interfaces that donât really mesh well together. Scene graphs were not meant to do immediate mode style rendering. At this point, I almost feel like everyoneâs life would be better if nifty just gave us a texture for the whole screen, already rendered.
Everyone in the conversation was talking specifically about the nifty implementation now since it was recommended by someone to try using it to do atlases instead of just using JME directly. I pointed out that the nifty implementation is non-optimal for this case. nehon said he fixed that issue. I said no, not really and that it was basically impossible (given the current nifty->JME implementation it is impossible). He agreed⌠then you start correcting me. Is it wrong that I would assume that you were talking about the same topic we were?
Bottom line:
an atlas is definitely the most optimal way to go.
nifty can technically do an âatlasâ but it provides no benefit over separate images.
fixing nifty to handle atlases well is on no oneâs to do list currently, requires changes (or some unknown level of impact) to nifty itself, and is a sizable change. ie: unlikely to happen in the near term. I agree that passing an ID or something means we could do something similar to the optimization done for bitmap text of the frame-coherent caching. I donât believe it will happen soon enough to matter to the OP. I guess we could also create a texture coordinate keyed cache without needing a change to nifty⌠but how far backwards do we bend to match up two interfaces that donât really mesh well together. Scene graphs were not meant to do immediate mode style rendering. At this point, I almost feel like everyoneâs life would be better if nifty just gave us a texture for the whole screen, already rendered.
Gha, will you stop it? I agreed already on all of that, just not on the additional point you brought in, which is me suggesting adding atlases to nifty to solve OPâs issue, I never did that. This was to not further confuse OP about what the options are.
Your accusing sounding âstarted correcting meâ is this little half-sentence that I took back when you told me the first time that I didnât get its the texture coords you talk about FFS: âBut they are only different when the layout changesâ. Also that you can live without Nifty for Mythruna equals theres no use in aiding people who are using nifty at a larger scale as the OP sounds quite a lot more indifferent than the pointless nitpicking.
How do you think this 10th thread of nifty hate will help the OP? You agree it could be a solution to this issue. Good. I guess I wonât answer GUI or effects threads anymore, people tend to get funny in these.
You said: âRight, the texture coords, I lost you three at the 8th detail of the nifty implementation.â
Then you said: âStill you now misinterpret me talking about Nifty again in the âlow level solutionâ I mentioned,â So I interpreted the beginning possible agreement as sarcasm.
I said: âEveryone in the conversation was talking specifically about the nifty implementationâ Iâm trying to explain why I thought you were still talking about nifty. Though itâs pretty clear now that you arenât.
Then you also said: âNifty could just supply better id-ing for objects on screen that jME is supposed to draw to solve this âcoord update problemâ if it is one, I bet Jens wouldnât mind thinking about it. They wouldnât even have to be collected or anything beyond one frame.â
My item (3) was attempting to address this.
No nifty hate here in this case. There is a way to make this work better but the current interface between nifty and JME is very limiting. I think everyone has to agree on that. I wasnât being hateful when I suggest that nifty just render to a texture and give it to us. For more than the most simple UIs, it actually gets rid of a whole bunch of problems. Itâs overall more efficient, nifty doesnât pick up our crappy BitmapText oddness, etc⌠I do wonder where the break even point, is, though. Is it 15 on screen controls or 50?
And this is what spawned the whole âatlas in niftyâ discussion in the first place. And thatâs when we dove into why it wasnât a good way. Later misinterpretations or not. I humbly apologize for then assuming we were talking about the OP doing an atlas implementation using nifty⌠apparently the conversation shifted and I did not shift with it.
@normen said:
After looking at the nifty docs, a custom nifty control that uses an atlas of buttons should be a breeze. And you keep the option to have the GUI layout separate as well as exchangeable for different platforms.
@pspeed said:
You said: "Right, the texture coords, I lost you three at the 8th detail of the nifty implementation."
Then you said: âStill you now misinterpret me talking about Nifty again in the âlow level solutionâ I mentioned,â So I interpreted the beginning possible agreement as sarcasm.
[snip, from here you further derail it towards nifty-jme micro optimizations]
Aha, okay. I guess just ârightâ never really sounds like âyouâre rightâ or âthats rightâ in english then, sorry.
