my UI extension got Rejected. Now what!!?? :P

As I said popular, they already got paid, and made money when you made say 100k from a business for say 3 months period, then the next 3 months, you give up and piss all over the people that bought your product..?? So you make another one, do you think people will trust you again??? Less likely, you made money off of them, they were popular for 3 months a year , 2 years what ever, that does not give them the right to keep selling it.. Take if off the store!!!! If your not going to support it, so my point is people keep selling a product and not support it, is the same as ripping people off..

also your way thinking is whats wrong with the asset store a few months... Funny... Thats why more of us devs aren't using the store and hiring real professionals and business people.... That way of thinking will not make you money if you have that of thinking, short terms maybe but your rep will be shot.. I bought popular assets and never got support or even a few months later when I needed the asset the dev disappears, if your going to do that stop selling the damn asset!!

@ Blizzy is correct thread is going off track. So I just wanted to reply to point that out...
@ Izzy so when you buy a game after a few months, I no longer need to support it??? That's the same thing.. I doubt you would be happy if that happen to you..

 

Any chance i can see a screenshot?
I'm a little curious if i can remedy this by using a Light GUISkin thats already part of the Unity editor?

 

There was a lot to read... interesting stuff.

I'd like to comment that the comic book super heroine's upper thigh is glowing blue, as if there were something magical going on in there. All joking aside, I actually do find it a bit offensive, which of course is my opinion.

 

Ohhh, Hellll Nooooo!
My poor baby.
What has the Dark Theme done to u?

Someone, gimme 1 cc Pro license! I must save my patient! ER Emergency! ... *humor*

Oh why Oh Why.. didn't I pick the Blue Pill?!
Well, thats gonna keep buggin me 'till I add Light/Dark theme defaults to the Preferences. :<

Thanks ZG.

 

I might also suggest having the option to disable hierarchy styling altogether. It might conflict with productivity tools that already do that, or custom tools. Ui is just one small part of a game, it doesn't need to be taking so much focus in the editor.

 

Thanks for the option reminder, I'm considering adding it, maybe sooner than later.
I'm finding the different kiss Component colors in the Hierarchy helps me locate and navigate the hierarchy faster. As far as quality of life features go, i'm giving it around 8/10.

I just wish there was an Icon or a way to mark certain objects in the Hierarchy, like say the kiss Layout object, have 3 vertical bars to represent that its using Column orientation for its children, or 3 Horizontal bars (like a Burger) for Rows. More like that.
Either that or have a different color, but thats too much for most to subconsciously do color association. It should be just a few colors to stay effective/efficient/productive.

I hope many of those Productivity tools already have a way to Filter out Which objects (by Tag, Masked Layer, attached Component Type, etc...) it should skip. Makes everybody Happier!

 

No, they are for handling the hierarchy, like QHierarchy.

 

Getting ready to Resubmit:



Description has:

About:

For anyone who wants to Build a UI by...

# adding objects in a Parent / Child setup to the Scene Hierarchy,

# using Rows and Columns to Reposition and Resize children like a table layout might.

# test your UI in the GameView, without having to press Play at all.

Features:

# Create your UI using...
Image, Text, Group, Layout, Camera

# Image State support for...
Normal, Pressed, Hover, Focused, Disabled

# Image State Mirroring...
Pass the images State to other images / texts. (ex: text color can change when hovering over an image)

# Input Handling (w/ Reflection) for...
Mouse, Keyboard, Touch (WIP)

# Multiple Input Handling entries can be added from the Inspector...
- Get values from Variables in any Components,
- Alter those values, then
- Set Variables to the new value.
- As well as, Call Functions in any Components and passing in parameters, using values Saved from previous calls.
- Simple operations can be performed All without needing to create a new User Script.

- etc...

any constructive critique?
Thanks.

 

@IzzySoft, that looks a lot better to me!
The description looks very much like a description of the Unity UI could look like. In the case that you have some unique functionality that doesn't exist in the Unity UI, you may want to point those out at the very beginning in order to illustrate it is not "just a clone".

 

The problem is, you can't know what unique functionality your asset provides if you don't know what your competitors provide.

 

Did you resolve the performance issues?

 

Ohhh, I keep thinking the description needs to appeal to users, so I listed things in order of appeal.

I will, once I'm happy my product meets my designer standards. Errr, i'm a little ocd when it comes to that, so it wont be any time soon.

 

Yes, the description does need to appeal to users...if a user reads a list of stuff the built-in UI already does, it's not appealing.

--Eric

 

Its most likely the Raycasting thats taxing the CPU on Mobiles.
I added the option to set the Update Intervals, while Playing... as well as while working in the Editor.

I haven't tried it yet, but.. I believe increasing the raycast Interval from 0.01 to something higher will reduce the CPU hit.
I might not really be able to tackle Mobile until i get to the Touch Input phase of researching, implementing, testing.

Ohhh, in the windows Desktop example, the DialogBox with the wrapping Text is the reason for the Resource spike.
I was testing how fast texture.GetPixels32 was with text wrapping. Only issue is that .GetPixels32 doesnt flush the GC. So, after 10+ minutes sitting idle, the standalone exe, or webplayer, frees the extra memory allocated. (ponders: *I wonder if forcefully flushing the GC when the user releases the mouse after resizing the DialogBox might do.*)

Just like, for Images, I intend to have Text have Single Plane (present), as well as Multi Planes later (each letter has its own plane mesh). It should be simple to add, just need time to do it. can't atm. :/

 

I dont think one product that on the surface seems to do the same thing (only by pure coincidence), but might have a slightly seeming odd / different approach, would make me run for the hills.

When I buy certain products, from the electronic store, I sort look to see certain if certain options are present.
If they meet those base requirements, then I look to see what sets it apart.

There will come a point (might be there already) where we have too many assets in the AssetStore or other sources, where every branch has been covered and little room is left for a totally new unique asset tool is possible. In that case, Unity might change their stance from Asset Tool needs to be "New and Unique" to "More and Improved".

Honestly, I'm just glad I got this far, and that I'm working on something I like. If and when the Asset Store accepts it, is up to them. Once kissUI is ready for production use, I wasnt planning on charging more than $50, only if it meets my standards. Might have go on sale every few weeks, so its 50% Off. ;D And thats the Pro version. Freemium version will have many of the features, with limits.

Thanks for the feedback, very much appreciated.

 

It wasn't just mobile, the performance hit was on pc/editor. On mobile it was just a bigger impact. (it didn't actually work on mobile in general.)

Recasting shouldn't be a problem on mobile. In fact it is much less, as you only need to raycast on touch, not like on desktop where you have poll the mouse position constantly. If I recall most the performance hit was from drawcalls and render updates.

That would understandable when competing against other third party tools, but in this case you are competing against a tool that is part of the engine, has deep (and wide) integration.

 

Ohhh... thats what i deduced as well, from my 1st try with Touch input.

As far as the CPU hovering around 40% when working in the Editor...
... can i ask what happens if you increase the Raycast Interval to say: 0.08



I have it at 0.06, and when not doing anything, but the Editor has the Focus still... it hovers around 5%.
I haven't upgraded my PC for what seems many years.

 

Yes, the performance is still unacceptable. This is a single image, which has 18(!) batches, 36 tris, and 72 verts.



If I duplicate this 50 times, I have 918 batches. Here's a Unity UI image for comparison:



Duplicating this 50 times results in still only 1 batch. With just having the images on the screen, it's over 4X slower than the Unity UI according to the profiler.

Note also how your image has single-pixel breaks in it, which appear and disappear randomly as the image is moved. I'm guessing you're using separate meshes for the slicing. It should be a single mesh, with shared vertices. You should also leverage Unity sprites, which already have things like 9-slicing and so on. This saves you having to spend all that time and effort rolling your own, and makes it a lot easier for users, since they can build on what they already know instead of having to learn a different workflow.

--Eric

 

Hmm. 18 for a 9 slice image. Are you redrawing the mesh or image data every frame?

 

​

Since i started working with 3D just over year ago, I'm learning the tricks of the trade.. as you might say. I agree that batching is an issue, and will include it based off of the Features the developer is using, or isnt using. If Tiling and Tinting and the like.. isnt being utilized on certain Images sliced zones, those images will become good candidates for batching. Still learning about the best optimized ways at the moment.

You can say this all started because I wanted to learn how to make my own Image Editor.
https://www.youtube.com/playlist?list=PLigySXrB56DtyT_6qwyGzdOVWfR0uNaDa

Even started a Forum thread here just a while back while working on the 9 Slice editor.

 

So you've got a tool that performs worse then built in, does nothing unique that built in can't do, and has worse support then built in.

This isn't going to be accepted. It provides nothing that a consumer would want to pay for. And nothing to convince the asset store that it will soon become a useful asset.

 

That's fine. The question is, is this purely for your own use, or do you want it published on the store and used by others? You did a lot of cool editor scripting, but it's not in an asset that's particularly workable right now. If you want to make assets for others, I'm afraid you need to ditch the "purity of vision" thing and do some research. Doing so is not in any way a failing, so don't think of it like that, since you end up with a product that's better.

--Eric

 

We'll get there.
Don't throw the baby out with the bathwater

If you mean to say its not Complete! I Agree! There's just Way More stuff i want to implement, and its still in early beta.
I will most definitely do more research, and maybe look to please other developers down the road when creating assets... but im still a n00b, learned allot in the process.

I think of this phase of my asset development as Prototyping where I get to Try out different approaches and pick and choose what seems to work best, without feeling/suffocating in any restrictiveness that approach might bring. Operative word being Try.

Once I figure out If/How i can apply Color Tinting, Tiling, Different Filters, etc... for each sliced zone, on a single mesh that's sharing Verts, sharing the same Material... I'll throw it into the Mix.

 

If you're just prototyping, it's way too soon to think about submitting it to the asset store.

--Eric

 

Its not ready for Production use just yet. So.. I guess so.

Goal Is/Was:
- Submit beta version of kissUI to asset store. (free)
- Use Asset Store like SourceForge to host, and get exposure for kissUI.. to other designers/developers. 2 birds.. 1 stone.
- Get lots of feedback over the course of development. Implement anything thats needed/wanted.
- Once out of beta, stable and production ready.. feature full.. sell for $50.
- have 50% off sales every few weeks.

Before the discussion in this thread, I was under the wrong impression that I could submit a beta version, like a number of other assets have done in the past. But things seem to have changed without me knowing. So here I am, soaking in the constructive critique, and hope to make a difference someday to future n00bs like I was.

I thank you and appreciate the patience and kindness shown. I know now this is a great community and hope it stays that way for a long time to come.

Thank you all.

 

I forgot to mention that in the Windows Desktop demo.. the Browser's client area (body) has an image called onScrollWheel that catches certain input events like the ScrollWheel (mouse wheel can be used to scroll the body), but still allows for input events to process for images underneath it as well. Its using the PassThrough after handing input events option.

This is handy too if you have many Small images and rather use One Larger image as a catch all for that Region. Could be used to switch focus between Dialogs, Windows, or whatever you want.

90% functional atm.. but I like how its coming along so far.

 

I'm not convinced there is a baby here to throw out...

 

I sorta know a little about a mesh sharing verts...



But I dont know if I can tile specific segments, like the middle one (5). If there is a way, it's way beyond me. :/
Any hints how to do it? Pretty Pweeese!?

 

Pro Abortion?

 

In this case yes. You would be better off abandoning this project and moving on with your life. KISS UI is a dead end.

 

See the bright side... I learned ALLOT up until now. How much more can i learn if i keep at it?
Be more positive. Not much lost, mostly gained.

 

If it is not production ready, you have to prominently state that, such that no one can miss it. I am not sure whether the Asset Store is interested in that kind of package, but you have to make it very clear to the potential users.

 

Two ways. Ok, three.
1. Math. You can make the center denser. Works ok if aren't scaling the object often.
2. 2 materials
3. 2 meshes.
4. Dynamically gen the texture

Ok. 4 ways.

 

Absolutely! I want the users to see that stated at the top.
But... does the Asset Store Frown on seeing that as well?

 

Ohhh.. so.. goes up to 2 draw calls. Hehe... I wanted 1 draw call. No dice.

I'll most likely need it to resize... so a few sections will need to tile...
2, 8 : Horizontal (separate mesh/material)
4, 6 : Vertical (separate mesh/material)
5 : Tile Both ways (separate mesh/material)
1, 3, 7, 9 : No tiling for corners (separate mesh/material)

Sooooo.... 4 Meshes? if user needs tiling on all sections that support it.
If its possible, i guess it would cuts down the number of draw calls by 1/2 of what it is now,
and possibly not loose any of the existing functionality.

Interesting. Thanks ZG.

 

When you publish something in the Asset Store that needs to be maintained over time, one of the most important aspects you are going to face is the trust from your customers. You have to be honest to your customers! You have to clearly state that it is a prototype or maybe an alpha version.
It is worth nothing to be in the Asset Store when the customers don't trust you!

 

Well, its seems like a few of the zone areas might need a separate mesh, but it Will only do simple tiling. :/
I dont think i'm able to specify only a certain rectangle on the texture it should tile... with just one Draw Call, like i have been doing already in kissUI with a separate material instance.

Desired:
- zone 5 could tile Zones 5 repeatedly to current size, with just one draw call?

ex: using the same Zones texture as before, can tile just a small part


This is already implemented in kissUI using a separate material instance, but i'd like to include this feature in any optimizations i make, if possible.

ex: Being able to do this would allow the users to use a single texture (platinum horizontal, or vertical.. not shown, etc.. others) to make a Dialog Box like this, which is possible atm with a separate material instance.


Thanks All.

 

In the worst case you would use submeshes rather than separate meshes. It doesn't help with draw calls, but at least it helps with frustum culling—since submeshes aren't separate objects, they don't need to be culled separately. Also easier to keep track of in code, and less memory usage.

--Eric

 

It's really an edge case. No matter how you do it you are going to incur an extra call. You could do it in shader, but even then probably two passes. Regardless, it's not a common need, and is easier dealt with in design than tech. An extra call for something like that is perfectly acceptable if the design dictates.

 

There is another possibility, which is what the Unity UI does if you use the "Tiled" option, namely achieving the tiling by using as many quads as needed:



--Eric

 

Heh, just did a quick test in uGui. It's actually trivial to get 1 draw call. Using 5 images (you could use more or less) and anchors, I just set the center one to tile, top and bottom are 9 sliced, sides to fill. 1 draw call.

 

Ohhhh.. why hasnt anyone mentioned this approach?

Step 1:


So the 3rd quad uses a smaller X for the UV.. and it looks inverted

Step 2:


Just make the 4th quad overlay over the 3rd quad?

Will this work on most devices? Maybe it cant!?

 

Not sure why anyone would use that approach, you could just do the math for tiling. It should work fine on devices, assuming the shader is correct.

 

Do you mean passing Math results to the shader? Got a link for the Math implementation? Hints?

If its that, wouldnt I need to have a separate material instance... so it doesnt affect any other meshes that is using the material? So an extra draw call?

I was thinking maybe the same material instance could also be used to Stretch a texture area, as well as Tile, to certain Quads?

 

No, not the shader, the mesh. Math for the grid. Calculate the border tris then the center part based on tile size. Pretty much just like in the wireframe image above.

You could do tiling in the shader, but it would be two passes, so two draw calls and dynamic batching would break. So two calls per instance. Mesh is cheaper.

 

Im kinda tired, brain wont compute.



Using this images bottom row, I want to just tile the 2nd entry.
I dont know what the X should be for the red Arrows in the screenshot above. :/

It just feels like its not meant to work that way, but i'm new to all of this.

Thanks for the hints though. Much appreciated.

 

The values should be the same as they ref the area on the texture. But will also be affected by the vert order.

I built some 2d mesh mapping tools that dynamically generates a mesh that maps sections of a texture to the UVs. Results:

I'll dig up the code in the morning and post some tips.

 

@zombiegorilla, much appreciated.

Sooooo, this isn't the way to position the Verts if tiling?
ex: Left to Right 1st: 0, 1. Then go up: 2, 3.

Right now, I can only get it to tile if I make certain Columns or Rows as fillers (hidden). ex:


Now I need to know!
I Must... Be... Patient.... *bites nails*