Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Grofit

Pages: [1]
1
Misc Archive / Re: Integrating aspects of uGUI further down the line?
« on: August 18, 2014, 01:16:06 PM »
Hey,

Thanks for the response, like you say I guess see how things go.

This all started because I was talking to a friend about gui libraries as he is wanting to look into gui for his project but has not used anything before. I recommended nGUI having used it and not really looked at uGUI (have done since that conversation), and he was saying that there is no point picking up and learning nGUI given that uGUI seems to be superceding it, and its free. I kinda agreed with his points but given that there are some features nGUI has that uGUI doesnt and vice versa I just wanted to know if you were planning on still keeping nGUI competitive or if you are basically looking to retire it or reduce your maintenance by refactoring some of your code to use uGUI so it becomes less work to manage etc.

2
Misc Archive / Integrating aspects of uGUI further down the line?
« on: August 18, 2014, 05:18:45 AM »
So I have tried to find out information on uGUI and nGUI and where there is overlap and what functionality is provided in one which isnt in the other etc. I also read previous posts here where you state the boundries of uGUI and nGUI and that you may further down the line look at incorporating some of uGUI features into nGUI and this is the focus of this question.

So currently from a primitive overview of what nGUI offers (taking support aside and just dealing with technical features), it seems like there is a large overlap in functionality (which I would expect given you did the initial work on uGUI) and you have mentioned before that uGUI can take advantage of certain performance benefits as it is part of unity core and it also has some new features that nGUI does not have.

Now looking at a new project currently I would be tempted to move over to uGUI given that the way you speak about nGUI is that you will maintain and possibly update nGUI 3 until end of the year but you do not sound (At least to me) like you have long term goals for it now. As currently it is basically going to be nGUI or uGUI, which if I were a betting man from all the things you have said so far and the route Unity are taking with it, uGUI will end up coming out on top. So I am just wondering if you have thought about the possible approaches going forward so you can make it less of a uGUI vs nGUI issue and have it so nGUI was just kinda built over uGUI to fill in the gaps and provide some additional features. As I would love to continue using nGUI but I would ideally want to know that given the amount of overlap I could at least make use of some newer features in uGUI if they do not appear in this framework.

I am waffling a bit, but I hope you can see the angle I am coming from, your network lib builds on top of the existing network functionality in unity, however nGUI is currently functionally comparable but technically incompatible with uGUI so I was hoping you could provide some more information on if/how you are going to reduce the incompatabilities and if there is a migration/integration roadmap in your mind as to how you would like to merge the 2 as much as possible to give devs the freedom to capitalize on the benefits of both systems?

3
Hmmm ok well thanks for taking a look, it may be down to them using 2 different cameras too, as although the lines are attached under your camera, I think vectrosity draws with its own camera, so will have to look into that.

4
When you use the scrollbars within the context of an NGui DraggablePanel, the scroll bars move the clipping area around (I am assuming) so it will show and hide elements based on the scrolled position (or internal position if the scrollbars are just updating some internal position).

Either way the reason I mention the scroll bars is because I am drawing the lines where the element should be within the scene (also viewed through the debugger to check they are correct which they seem to be) but the elements appear elsewhere in the actual game so I am just wondering if given the above psudocode for drawing a line between 2 NGUI objects am I missing something which is specific to how NGUI operates? As I am still a novice at unity, so it can be a bit confusing when there is a main camera, and another camera in the NGUI part but this displays within the main camera anyway, so I could be missing a transform or some translation due to the way NGUI is rendered, especially when its being offset by a draggable panel with scrollbars.

So that is why I mentioned them, and was hoping someone who has more experience with NGUI/Unity would just see straight away where I am going wrong with the getting and assigning of the points to world space etc and just point me in the right direction.

5
NGUI 3 Support / Vectrosity lines between UI elements with clipping...
« on: August 16, 2012, 04:37:25 PM »
I have got an issue at the moment where I am using Vectrosity to draw lines between certain UI elements whilst clipping, it is for a large map so I want to pan around and draw lines linking areas of importance to each other to show trade routes etc, currently I am using something similar to this:

  1. var uiElement1 = // Some Element, lets say texture
  2. var uiElement2 = // Some Other Element lets say texture
  3. var uiElementContainer = // Some panel which contains all ui elements
  4. var guiCamera = GetComponentInChildren<Camera>();
  5. var transformedPosition1 = guiCamera.WorldToScreenPoint(uiElement1.transform.position);
  6. var transformedPosition2 = guiCamera.WorldToScreenPoint(uiElement2.transform.position);
  7. var line = VectorLine.SetLine(Color.red, transformedPosition1, transformedPosition2);
  8. line.vectorObject.transform.parent = uiElement1.transform; // Add under uiElement 1 to clip when it moves off the panel
  9. line.Draw3DAuto(uiElementContainer.transform);
  10. line.lineWidth = 2;

I can fully appreciate that you cannot offer any support as far as vectrosity goes, but if we just assume it acts like a normal game object for all intents and purposes, the problem is that it doesn't seem to scroll properly, its like it scrolls 1/3 the speed and is 1/3 the size... I am assuming its down to the WorldToScreenPoint usage or something but I am no whizz when it comes to 3d transforms so am wondering if there is anything special I need to do to get object displaying correctly when scrolling?

On a side note I am surprised there are not more Vectrosity + NGui questions...

6
NGUI 3 Support / Re: Clipping Simple Textures within Panel?
« on: August 16, 2012, 01:12:49 PM »
Right! got it working, I had 2 panels, one was a container for multiple elements, one of which contained the texture, now it works as intended, but it looks rubbish because of the transparency, but thats a seperate issue :)

While kind of on the subject, how would you recommend going about grouping NGUI elements to make hierarchies in the project? i.e.

  1. Anchor
  2. |- Camera
  3.     |- Panel
  4.         |- Background
  5.             |- Texture
  6.         |- Content
  7.             |- Label

I tried using empty game objects, but that seems to mess up the transforms for subsquent children.

7
NGUI 3 Support / Re: Clipping Simple Textures within Panel?
« on: August 16, 2012, 01:08:10 PM »
Thanks for the quick response, currently am only running on windows, I did see a similar topic recommending using a different shader. I have just tried using Unlit/Transparent Colored but it doesn't appear to clip the texture, I am also using the free version of NGUI for the moment. I remember you posting elsewhere saying that the free version didn't have all the bug fixes the paid version has.

8
NGUI 3 Support / Clipping Simple Textures within Panel?
« on: August 16, 2012, 09:34:31 AM »
I have a panel with a NGUI simple texture beneath it, but for some reason the panel isn't clipping the texture, is this correct behaviour? I am using Hard Clipping but have tried Soft and Alpha too...

Pages: [1]