Official: How Can We Serve You Better?

Actually, I believe you're replying to an older post than when you gave the list.

 

We got some new crashes and hangs in RC5, that didn't exist in RC4.
Bugs are logged but they are not debug related

 

For this kind of thing, and if you don't want/can't open up beta to all pro users, could it be possible to open up more the beta forums?

With only read access, we could go and see what to expect from the next release, and see what's bloking its release.

 

The topic of the post was "how can we serve you better". Seems folks were fussing about the graphic output of other engines "out of the box". If the defaults can be better set out of the box then this alleviates the time of setup to achieve a decent look to go about tweaking. The generic answer you gave is obvious to myself as an artist trained originally as an oil painter and familiar with chiaroscuro and the diligent use of light and shadow. The technical answer lies within settings such as the light bias, how far away from the light a distinct shadow would be cast before the spread of the beam was dispersed too wide to offer detail.. Are the lights inverse square falloff, linear..what? Can we have a choice via checkbox for various falloffs? What is a good angle to use on spotlights to get best shadow detail or does that matter?

I have had both awesome and WTF looks from the Directional Lights.. What is the trick there? Scale of model? What does the cookies width have to do with it. Is it best to use a large number or small number for the cookie width when lighting a terrain of say 1km x 1km and the camera is a 3rd person camera and close on the character but seeing the terrain hundreds of units distance in the camera frustum. Are there better shaders that could replace the standard ones and if so why are they not included? PBR shaders are a good step forward though the Asset Store ones do not razzle dazzle me out of the box. The detail gets lost in the specular which is critical for normal map details to pop.

A set of shaders that come standard should include a reflective dome shader that does the work of camera mapping the environment to a dome (or better yet a spherical map) used on the shaders surface based on surface normals and fresnel mapping. Most real world objects have some fresnel reflectivity. The ability to use gradients in some shaders based on normals for fresnel type effects or in various specular and texture channels would greatly extend the ability to tweak in Scene instead of jumping back and forth to an image editing program and using custom written shaders to implement the ramp per channel. As well it seems to me that a gradient can be done algorithmically and a ramp map has to have an image loaded. In many cases this could be used and significantly lower file size as the ramp maps would not have to be loaded.

Could an algorithmic 3D noise shader be implemented as a standard shader type that calculates the 3D noise from the objects origin and then uses the object surface to capture the noise at that point. UV map setup would then not break the noise texture at its seams.This would also bring down file size and allow quick "look" iterations and be very useful on terrains, terrain objects and other objects needing a noisy surface to add to their faked realism.

Per Anders of C4D fame wrote a set of guidelines for setting up lights, the contrast setting best used, shadow percentiles and the use of color versus a straight black, what AA settings, type of shadow to use, gamma settings and a number of other defaults that could be tweaked that when implemented definitely brought forth better renders. The ability to save this as the default light settings and renders setup was shown as well. I haven't seen anything similar as a set of guidelines for getting a set of defaults that leads to a good starting point to tweak from. If you put a cube on a surface with a good texture map with normal maps that renders near photorealistic in a 3D app with one decently set up light source, and in Unity shine a spotlight on it..it is not close to looking good in Unity.

 

This might be a great idea...

 

Don't know how feasible that is, but can you maybe also add the number of issues you still need to deal with. That will work like a countdown, and people love countdowns

 

That's a good one.
It would be even better if you could specify the number of the released alpha/beta/RC too.

 

Hey all,
So I'm going to close this thread in the next day or so (Tuesday-ish). So feel free to keep posting here. I'll post the summary again before it's closed.

Meanwhile, please give us some feedback on 2D, Input and Particles [bugs, workflow, integration, missing functionality, etc.]:

http://forum.unity3d.com/threads/248095-2D-Improvements?p=1640636#post1640636
http://forum.unity3d.com/threads/248098-Input-System-Improvements?p=1640646#post1640646
http://forum.unity3d.com/threads/248094-Particle-System-Shuriken-Improvements?p=1640627#post1640627

Thanks!
Brett

 

Something I can think of:

- event for resize. Right now, there is no resize event, when the screen size has changed, or the screen dimensions has changed.


Can there be a new event for this?


Right now, you have to check each frame for the cached screen dimensions and adjust your resolution metrics accordingly.

 

Love it.

 

+1.

Please don't forget to add dates when its updated and the version # to each of those dev branches. That way we can know if its the news is current.

That status information can quickly become irrelevant if it feels like it's an afterthought and you cannot track real progress.

Example;
- 4.5 RC4 (2014-05-26)
- 4.6 Beta 7 (2014-04-29)
- 5.0 Alpha 1 (2014-05-15)

I don't know if its possible, but the best solution would be to merge that with the roadmap idea and show the release notes given to the testers for each release.

Thank you.

 

I'm not even trying, and I still get all that information from rumors already. Knowing that a beta can last for months I don't really feel this gives enough information. The best would be a straight up ETA (with emphasis on estimated). Running late? New bugs popping up? Update the ETA.

 

(see above)
That's why I'm suggesting that if they post their internal release notes so you can track, estimate and predict what's going to be in the release.

And it doesn't require them to do extra work, just copy paste what they already do internally.

Acts as both the ETA/Status Update and the short-mid term Roadmap.

Win-win?

 

That is a start, albeit slow start.

If this was 2008, yeah, that'd be great.

What are you using on the backend? JIRA? Confluence? Something that has burndown charts I am sure.

Why not just publish a daily burndown? You can export that from whatever tracker you are using (I would seriously hope).

I don't propose giving full on access to the tracker, but, why not? Read only access, why is this a problem?

Are the things you guys add release to release such a safe guarded secret for some reason?

A lot of modern projects (this is not a pro-UE4 rant) are switching to expose the development pipeline, and I don't really see any paranoid rumblings coming after the fact.

I am also at a loss as to why this project has not opened the beta stage for ALL users. Keep the alpha closed, but still show progress on where it is at, and have a much wider beta.

Your cycle(s) are simply too long for people to wait around given the heat growing with your competition now. Your current model worked 4 years ago; that was 4 years ago.

 

It's 1:40am so I hope what I'm about to say is coherent.

A huge boon would be splitting Render and Physics layers, preferably on a per collider level and multiple layers per collider/renderer and separate lists too. Having 32 layers to share between renderers and physics can get painful in some situations. And since layers seem mostly to work with bit-fields this should be damn near trivial to implement.

A method to explicitly tell a rigid body which colliders are attached to it would be great, instead of relying purely on hierarchy.

And passing arrays of values to shaders, not sure why that's not in there yet. There are methods where you can pass data baked into textures but getting multiple values out of that texture is expensive (texture lookup per query is awful).

 

On the topic of layers, they're so restrictive for me that I don't use them on account of objects only having a single layer. For instance, I can't have something that is on layers "Clickable" and "FootprintSurface". Obviously there are plenty of use cases where you'd want to be able to mix things like that. And since you can't do it with the layer system, I avoid it like plague in case I need to mix whatever I'm doing with something else later on.

As a result, the only thing I use layers for is when it can't be avoided (raycasting) or to de-clutter the scene Editor (hiding layers).

It'd be great if an object's layers could be a field mask. Currently, for instance, "FootprintSurface" is a marker component that I drag onto things I want footprints to be able to appear on. That works fine, but it's a tad more of an overhead than it has to be considering there's no extra data attached.

 

Also, I just want to say that the various [Official] threads popping up are great and I for one really appreciate them. Keep up the awesome work!

 

Thomas, don't let them get to you ;-) It's noble for you to defend yourself, and your department, but realize that some just keep drilling until they hit a nerve. The reality of bugs is the same in any company. We all have "Do it right, make it robust" vs "Do it now, get it to release, generate revenue" to balance between. I'd be lying if I said that every product we made was done right from the start and, in theory, had small bug backlogs... It's just the nature of business drive vs development control and should never reflect on the company, or department, in terms of quality of product! Don't let them get to you buddy, some people just want blood...

 

I would propose giving access to the tracker, AT LEAST read only, and ideally bug filing/attachments/commenting/voting capacity as well. This would ultimately be the best solution available for addressing the "black hole" comments a lot of people have been making about bug submissions.

Speaking of Jira, Atlassian (who makes it) runs their production instance of Jira exposed to the public, and it's really valuable.

 

@bibbinator,
The past years we've been working on an episodic survival horror game called Forgotten Memories which is now finished and will be soon published on iOS (upcoming episodes are being worked on), If you want to know more follow the links on my signature.
I privately and regularly speak with Unity devs (my last interview and feedbacks was with ex-Crysis AI lead developer which is now working for Unity on some secret sauce). Besides giving them lot of feedbacks about upcoming features, I do report tons of bugs and hack their new toys. My thoughts are probably a reflection of what people are already issuing/talking here (the main one being licensing costs).
We have a multiplayer project in the works and we are prototyping it with UE4 right now because of it's awesome built-in networking capabilities but we are also keeping an eye on UNET and see how things goes there. Basically, we'll keep Unity for a while as we have a small team currently working on Forgotten Memories episodes content but we'll possibly entirely move everything to UE4 once we are done with all episodes later this year (it would mostly depend on UNET).
I'm not looking for wow AAA graphics. Unity, UE4 or whatever big commercial engine is pretty capable if you got the skills to do it (even if some of those engines have out of the box wowsomness). What we are looking for are tools that helps us improve our workflow and iteration faster and world class dynamic open world capabilities: easy/faster way to stream data, parallel processing, multi-threading, paging, tiling, client networking interpolation and predictability. Anything that helps creates more open-larger worlds that are fluid, smooth, seamless is what we are looking for. If a tool doesn't provide such functionality out of the box at least it should allow us to make it happen.

 

I know companies who delivers both, an open beta version withouth any warrantys, and the latest stable version. Which makes the question when the next version arrives obsolete. It is always there with the next open beta release. And Open beta testing guarantees a much more stable product. There are much more eyes looking at it that way. Of course given that the reported bugs gets fixed then.

The crux of the matter is that as a user you may run into not expected bugs up to a ruined project when you use a beta version instead of the latest stable version. And it may make more work for Unity when normal users starts to report beta bugs too.

 

And multiple tags per object! We can have multiple labels in the editor, we need them in the game!

 

Hi, I am working on this now, and hoping to introduce this feature sometimes in 5.x releases. The benefit is not only providing standard JSON API in Unity, but also provides significant memory performance improvement compared to popular C# JSON implementations often used with Unity. The code is still work in progress, but we see roughly 8x performance improvement with 1/3 memory consumption.

 

How exactly would you like this to work? I've seen a lot of different JSON implementations with a lot of different pro's and cons.

 

Hey all pigeon6:/D is a Unity employee. We'll get his tag fixed, but just letting you know

He's talking about a native integration into the core engine.

 

Good news! I love native integrations

 

Cool stuff, when you're ready it'd be interesting to see a thread on this - to see what the pro/cons of your implementation is.

 

Stop charging for extra platforms. No?! Well then...

 

Hey all,
Reminder I'll be closing this thread soon with a summary (probably leave it another 12-18 hours).

Also, in case you didn't see it already, Unity 4.5 is now out (with over 450 bug fixes too )

http://unity3d.com/unity/whats-new/unity-4.5

 

After seeing 4.5 module downloads I'd like the module window once it checks for updates to remain separate from the asset store window.

 

Or at least half the current price of an add-on for all the add-on would be a start... $750 for all add-ons...

 

For me personally, I want to be able to serialize standard .NET 4.5 classes from my MS .NET Web API and have them deserialize in Unity using the same class and attribute markup and vice versa. Currently with the asset store package that I'm currently using (don't have name as I'm at work) I have to remove enums to get it to work. I think there's at least one more thing that was annoying me but it's been awhile since I've worked on that part of the game and my brain no worky that good with the memory anymore.

 

That's good to hear, thank you. As I've already stated, I'd be happy if it just works with MS .NET 4.5 JSON (de)serialization out of the box.

 

Regarding serialization, here's one thing I consider a bug:

Enums are serialized by their index in the enum definition. So when I add something new to the list, my MonoBehaviour scripts are pointing to the wrong value now.

For example:

Code (csharp):

1. enum Race {
2.    Human,
3.    Dwarf,
4.    Elf
5. }

Let's say I have a script using it and is currently set to Dwarf.


When I change my code to this:

Code (csharp):

1. enum Race {
2. Human,
3. Goblin,
4. Dwarf,
5. Elf
6. }

My script will now be set to Goblin, because it's the new 2nd entry in the list.


Not exactly sure how to fix this really. I'd initially say, use the enum name instead as a string when serializing, but what if I rename my enum values?

It's made me reluctant to use enums at all for areas in my code that change a lot, when I have such things.

In my own serialized data (I save some things in JSON when I want to let the player change it) I save a version number. Then I have my own equivalent of that new ISerializationCallbackReceiver to resolve values from old versions.

 

Additionally, I have a suggestion: we should have these [Official] threads be in their own forum section, instead of being in the Gossips.

 

The solution is to assign specific int values to each enum. If you started with:

Code (csharp):

1. enum Race {
2.    Human = 100,
3.    Dwarf = 200,
4.    Elf = 300
5. }

Then later you could add one:

Code (csharp):

1. enum Race {
2. Human = 100,
3. Goblin = 150,
4. Dwarf = 200,
5. Elf = 300
6. }

And you're original values would map to the same integer values. It's helpful to do that when exposing public enum values to the inspector too.

 

That's clever, I feel stupid for not having thought of this! Thanks!

 

Fix your bugs.

I bought Unity 4, upgraded, ported my Unity 3 based game, then soon after, a regression appeared, breaking SkinnedCloth.

With the 4.5 release just out I was informed that this bug will not be fixed until Unity 5.

Over an entire year waiting for a single bug, and waiting in vain.

I never even used Mecanim - it was so useless at the start I just continued with the "legacy" system to the point where porting to Mecanim would have been more trouble than it was worth.

I warn anyone that thinks Unity 5 will be anything but a buggy waste of money to serious consider staying with the buggy version you know rather than upgrading to a new buggier version. I would have been better staying with Unity 3 (I had worked around most of the bugs in that). Don't let slick salespeople fool you (I was contacted personally at Unity 4 pre-order time by a salesperson and convinced to upgrade by their seemingly new-found earnestness to fix bugs that had plagued Unity 3 - all smoke and mirrors).

And you wonder why customers are angry and gleeful to see you squirm under epic competition? You brought it upon yourselves.

 

Hmmm... I didn't want to start a new thread, and didn't see this pointed out elsewhere, but when did the Doc change?
http://docs.unity3d.com/ScriptReference/index.html

Very slick, and much easier to navigate. The big things are always welcome and anticipated, but the little things are nice too. Great job!

 

I'm a programmer for a small UK based Indie. We've shipped several mobile games (3d 2d) using Unity.

Bugs! We take time and effort creating a sample project to send with the bug report - it would be nice if you could take more time in addressing them (or at least acknowledge them). And you say that you prioritize bugs for the latest release - well I suppose the bugs I submitted for the (then) latest release will probably never be looked at now as there's a newer release.

 

Yes, it's looking good now, and if I did another project with Unity, I'd use it. But this is the entire problem: a feature is only of full quality for the later months of the update cycle, then it starts all over again with version x.0.

 

How Can We Serve You Better?

You already are now, I've seen a marked improvement on this forum with Unity staff playing a much more active role. Not just this thread
but lots of other ones too. It kind of makes you feel like we haven't just bought a product and told to get lost, which is how I felt before. On other threads people are reporting lots of problems or suggestions or concerns over the 4.5 release and rather than just ignoring people on here like I felt you used to, you are at least now engaging your customers better on here.

I just hope it's not a fad and you can keep it up.

One last thing, you need to have way better support for the Oculus Rift built in to the engine and optimise it so it works seamlessly, The rift is going to be massive imo so please stay on the ball with it.

 

Hey, that's very nice, thanks for the info!

 

For me, I'd say the biggest concern is the price of the add-ons. Having already paid $1500 for Unity 5 pre-order ... I really feel another $3000 for two more porting options is excessive.