UNIGINE 2.0

[ulf.schroeter]

RAMPAGE!!!

Wow, so much emotions for so little trouble...text editor e.g notepad++, replace in files ".childs (" with ".children ("... finished within 60s

[cinetec_tech]

we need make this clear.

Will unigine editor source code accessible for FULL source code licensee from now on? Or just API?

If we can't make any change to the editor code, basically we can't use unigine upprades anymore.

We have 80K lines of codes based on the current editor and it's impossible for us to make those work without the access editor source.

[alexey.egorov]

Wow, so much emotions for so little trouble...text editor e.g notepad++, replace in files ".childs (" with ".children ("... finished within 60s

for ten years this things have been hurted souls of the english-speaking people.

so, OWNAGE!!!!!

[necris]

Managing licenses article was updated.

Please check it if you have any questions about offline lisense activation.

[demostenes]

Managing licenses article was updated.

Please check it if you have any questions about offline lisense activation.

 

What happens, when licence expires? Logically updates will be not available anymore, but editor should run forever. Am i right?

[elvieness]

You are right. When the license expires, updates become unavailable, but you still can use tools (including UnigineEdtior) and engine functionality.

For Evaluation kit licenses, updates, support, tools and engine functionality become unavailable.

[esger.abbink_]

Managing licenses article was updated.

Please check it if you have any questions about offline lisense activation.

 

"The SDK Browser manages licenses for the current PC: in order to use the UnigineEditor or debug builds of the engine, it is required to keep the SDK Browser launched."

 

Uhm, this is quite inconvenient.. What might be the reasoning here?

 

 

While developing software we use debug builds (for debugging purposes), we almost never use sdk browser while developing software. I've described earlier that about the only thing we use it for is to quickstart a demo to check something. Other than that, it doesn't have much use for us. Having to run just to "have it running" is a inconvenient and a hassle.

 

While debugging problems in a simulator, which may consist of quite a number of connected systems where normal keyboard/mouse access to each pc/screen is mostly not present or necessary, we use the debug versions of the engine. Having to wedge an sdk browser in there on each computer system in a simulator again to just "have it running" is inconvenient to put it mildly.. to put it more bluntly, it's a pain we rather keep doing without..

 

I have to agree with Ulf here, these kind of changes (sdk layout, standalone no source editor, sdk browser, etc) have huge impact on productivity and usability of the Unigine engine. It would be far better to announce (desired) changes with reasoning and allow an opportunity to have customers give feedback on how those proposed changes impact their respective work flows and uses of the engine. Instead of dropping sometimes serious problems out of nowhere. Now with several items Unigine is invested in a change (made a commitment in time and money) while for some/many customers the change negatively impacts their use of the Unigine engine. Meaning, somehow afterwards either Unigine or customers (possibly duplicated effort here on top of things) need to mend things. Increasing the amount of effort needed, and quite possibly not resulting in the best solution for the customers as is usually the case with mending things that weren't broken before..

 

And it detracts from actually using the great new things that are also present in each new release in the shortest time possible.

[werner.poetzelberger]

Hello,

 

I dont want to moan here, but today there was a problem connecting the sdk browser to ther server (??) so I couldnt work with my project.

 

This was just for some minutes, but that is definitely a gamestopper.

 

Working with the old Quest 3D, the company decided to integrate an online license check on every start, which really was so annoying, as there was no reason for that. For us now, working with old projects (we have to maintain them) this is a huge risk factor, as these licensing option may die one day and I am not able to edit these projects any more.

 

So I really don't appreciate these online licensing checks, at least I do not see any benefit.

 

best. w.

[demostenes]

So I really don't appreciate these online licensing checks, at least I do not see any benefit.

 

 

 

Agreed, browser is crashing on my computer, so I am not able to run editor. And these problems will continue. One month ago I was installing UE4 (I needed to extract some assets I bought on their asset store) and their browser wasnt downloading editor binary. I spent whole afternoon with their support to run that crap (lots of their users have these problems). And why? Just to download editor installer. I really dont like these installers/browsers. Unlike Unity3d Unigine community are not kids, so we really dont need these trouble causing solutions.

[binstream]

Some of these tools are new, and despite the fact that we have improved them a lot with recent updates, there might still be some bugs. Sorry for that, we are working on making them as stable as possible.

Anyway, there are standalone builds available for customers who want to have SDK in one piece, even if it means downloading more data.

[thomas.heinze]

First of all a big compliment to the whole Unigine team on the 2.0 release, everything is top notch.

 

 

Known issue: El Capitan (Mac OS X 10.11) is not supported at the moment (update will be available shortly).

 

 

Any news in this regard? We just started evaluating Unigine, and about half of our machines are running OS X El Capitan. Is it wise to downgrade to Yosemite in the meantime, or is the update right around the corner?

 

Cheers, Thomas

[binstream]

Unfortunately OS X El Capitan is not backward compatible in some cases, but we are working now on supporting it as well, ETA for the SDK browser update is about 1-2 weeks.

[ExBemined]

While debugging problems in a simulator, which may consist of quite a number of connected systems where normal keyboard/mouse access to each pc/screen is mostly not present or necessary, we use the debug versions of the engine. Having to wedge an sdk browser in there on each computer system in a simulator again to just "have it running" is inconvenient to put it mildly.. to put it more bluntly, it's a pain we rather keep doing without..

To make this worse, it seems you can only run the browser once per account, I noticed this when I wanted to install the Unigine SDK on two test computers at the same time, one of my browser sessions got automatically logged out. Would we need to create 'dummy' accounts on the developer site for each test computer, or is there a way to login on multiple stations at the same time for debugging networking issues?

[binstream]

Release builds doesn't require sdk browser connection. If you need to use debug ones, using another account for test machines would work for now.

[esger.abbink_]

Hi Esger,

 

Sorry for the late reply.

 

RIght now we are in the middle of a designing a new structure that will not change drastically anymore. More information will be available before the SDK release.

 

Thanks!

 

Due to a number of issues pressing for my time I have not yet had the chance to take a new extensive in-depth look at the sdk structure and I don't have the previous version on hand here at the moment to make detailed comparisons. It would be appreciated if you could elaborate on changes made with respect to the issues raised? (see also https://developer.unigine.com/forum/topic/3347-unigine-20-release-candidate-ide-integration-pbr-improvements-bugfixes/ from around post #11). My apologies in advance if I am missing some more subtle changes, but from a glance I do not see that much difference, meaning many issues are (for us) unresolved?

 

Lacking the time for a more in-depth look at the new version I am also echo-ing other voices that both a binary only editor and a standalone editor are huge turn-offs. We have extended editor functionality (for instance tracker both in parameter types as well as editing functions) in the past to match specific type content and the in-application/in-scene editor has seen many many hours of use both polishing things or tracing bugs.

 

 

Some of these tools are new, and despite the fact that we have improved them a lot with recent updates, there might still be some bugs. Sorry for that, we are working on making them as stable as possible.

Anyway, there are standalone builds available for customers who want to have SDK in one piece, even if it means downloading more data.

 

I think the point here is that there are bugs causing issues when working with the new version stemming from new functionality that seems unnecessary or is actively unwanted.

 

Due to lack of time I cannot give a more detailed opinion/response at this time, but whereas we are certainly very enthusiastic about the technical strides forward being made I am quite concerned about a number of other aspects pertaining workflow issues, continuity, etc and what kind of impact they have on longterm usability. When we made the choice to go with Unigine this was on the basis of perceived quality and features present. A number of those features now seem to be gone or seriously hampered. Who's to say which unannounced roadblock is dropped with a next release?

 

Again, I also see great things in the new release but updating will mean quite a bit of work and as it stands now it begs the question whether updating is worth it at all because a number very useful and worthwhile things are lost. Which of course isn't a viable strategy long term, but thats kinda the point..

[binstream]

This was a release with a lot of important changes, and some of them are not 100% polished, I agree.

Thank you everyone for valuable feedback, right now we have changed priorities inside the team to address this roadblocks first thing:

* Editor release/debug build

* License key management

* Loading editor for a launched application

[thomas.heinze]

Unfortunately OS X El Capitan is not backward compatible in some cases, but we are working now on supporting it as well, ETA for the SDK browser update is about 1-2 weeks.

 

Thank you for the heads up, that is very good to hear. In the meantime IT installed Win 8.1 via Bootcamp.

 

Cheers, Thomas

[esger.abbink_]

Werner, my statement was - of course - only targeted towards Unigine crew. The key problem is that they made quite fundamental design decisions, already invested a lot of resources for implementation. Under these circumstances it's quite hard to accept that maybe this new approach might be a complete dead end which should be rolled back immediately to minimize harm...nevertheless in practice natural reaction is to keep on moving with the wrong approach and trying to reduce some of the key issues by some work-arounds...but this would be bad both for Unigine crew and customers...therefore my harsh words, simply hoping that this might be some motivation for critical rethinking the new approach

quoted from a different thread (https://developer.unigine.com/forum/topic/3548-huge-performance-difference-between-editor-and-release-version/#entry18772) but it seemed more appropriate to respond here

 

Again, I have to concur fully.

 

It is very good to see that issues are quickly acknowledged and are given priority. At the same time I am not convinced the "combatting the symptoms instead of the disease" phase is being skipped here..

 

Everybody understands that these issues in Unigine 2.0 can't be fixed in a day. That much is clear. And a number of changes might make things more workable and so could ease things for the immediate future.

 

But while I think that is worthwhile as short term solution, I think it is also important to not lose sight of a 'good' solution as well. A bandage might be better than an open wound, but it's still a bandage.. If not, Unigine might make the same mistake again while trying to fix things: making changes (ie. making design choices with a serious impact on customer workflows) without consulting and/or checking these with their customers resulting in "moaning chorus - the rebirth"

 

This may indeed mean rolling back and throwing away investments because of re-evaluation of certain design choices. While this is of course a pity I agree wholeheartedly with Ulf, better to make a clean break than to walk down a long road of applying band-aids wasting time and money on both customer and Unigine sides. So I would suggest it to be very beneficial if Unigine, in addition to short term fixes, opens a dialogue here about the changes made. To see if they make sense and what their impact is for customers, whether they should in fact be rolled back and so Unigine can listen to input before choices concerning these or new issues are made. Focusing new efforts on what is most important: delivering an engine and tools that have a positive impact on customer workflow and endproduct quality.

[z-elements]

Hello! How does the post_sensor? And where can I find it?

[sergey.pozhidaev]

This was a release with a lot of important changes, and some of them are not 100% polished, I agree.

Thank you everyone for valuable feedback, right now we have changed priorities inside the team to address this roadblocks first thing:

* Editor release/debug build

* License key management

* Loading editor for a launched application

how use editor for a launched applications?

[silent]

sergey.pozhidaev

 

Right now it is possible only if you launch Editor binary (editor_x64 / x86) directly.

[silent]

z-elements

 

Check the unigine_sensor material library in Sim SDK.

 

You can inherit and modify any of the following materials:

• post_sensor_green
• post_sensor_heat
• post_sensor_red
• post_senro_white

To enable this post effects just type inherited material name into Windows -> Rendering Settings -> Post field.

 

Thanks!

[z-elements]

Thanks, silent!

I have the UNIGINE 2 Sim. But there's no the unigine_sensor in the material list. Where can I find the unigine_sensor?

[silent]

z-elements

 

It is a material library:

 

[z-elements]

silent

The unigine_sensor doesn't work. It's can't find the files: sensor.vert, sensor.flag, sensor_process.flag.