OctaneRender™ Standalone 1.14

[arh-osa]

Thank you guys!
Little issue to fix: Background image doesn't work if path contains non-latin (cyrillic) characters since this feature exists.
Please, fix it

[abstrax]

Thank you guys!
Little issue to fix: Background image doesn't work if path contains non-latin (cyrillic) characters since this feature exists.
Please, fix it

Thanks for the heads up. Will be fixed with the next release.

[pixelrush]

Well all I can say is if there are things going on it would pay to at least make that known.
You will be aware that when Refractive ran things community confidence went into a dive and relations became quite hostile as nothing appeared to be happening and from the outside that's beginning to look how things are again.
Its entirely up to you what you do about it but if you don't say anything and only deliver what looks like small stuff or that the community dont regard as particularly important you can expect some criticism for the apparent lack of progress. I haven't noticed any negative comment about spherical camera itself only about the cluttered UI. Perhaps people forgot to be complimentary when identifying faults or immediately thinking of the next thing they want.
Now you get the pip because we do or dont say so and dont want to talk to us. You say you just ignore comments and suggestions you don't like or view as pertinent and regardless of any solution offered you seem to do your own thing anyway. OK so its your code and your business. Obviously you guys really have your own larger internal agenda set by Otoy and may view the users requests as a bit of a pestulance in that regard but you run the risk of alienating people with this approach.
Octane is not the be all and end all of renderers. It is a particular technical solution. You have to see your business in the broadest sense and keep moving ahead with it . Cycles is developing faster than Octane. Indigo was a one man band and moved faster than your team do. Regardless of the trickiness of coding for gpu people have expectations for the rate of development of something. I dont know what you are working on with 2 people for a
year and havent finished but I would think people would be hearing that and asking themselves if it is worth it when there are a list of things they possible could do with already that would not be so involved.

[abstrax]

Well all I can say is if there are things going on it would pay to at least make that known.
You will be aware that when Refractive ran things community confidence went into a dive and relations became quite hostile as nothing appeared to be happening and from the outside that's beginning to look how things are again.

I certainly hope that we don't make that impression.

Its entirely up to you what you do about it but if you don't say anything and only deliver what looks like small stuff or that the community dont regard as particularly important you can expect some criticism for the apparent lack of progress. I haven't noticed any negative comment about spherical camera itself only about the cluttered UI. Perhaps people forgot to be complimentary when identifying faults or immediately thinking of the next thing they want.

The spherical camera distortion was requested from OTOY so Andrey added it quickly. We are currently in the process of stabilizing the code and release a stable 1.20 as soon as possible. We already have a bunch of features to be released after 1.20.

Now you get the pip because we do or dont say so and dont want to talk to us. You say you just ignore comments and suggestions you don't like or view as pertinent and regardless of any solution offered you seem to do your own thing anyway.

No, that's not what I said. I said that if people complain about missing features in a release thread we pretty much ignore it, because it's the wrong place and we have to filter through pages and pages of rants to get to the actual feedback we are looking for. We only have so much time. And again: The better a requested feature is described (especially considering the node system and standalone UI) the easier it is for us to get an idea how to implement these things. Writing it in a separate thread certainly helps, too.

OK so its your code and your business. Obviously you guys really have your own larger internal agenda set by Otoy and may view the users requests as a bit of a pestulance in that regard but you run the risk of alienating people with this approach.

I can assure you that's not the case.

Octane is not the be all and end all of renderers. It is a particular technical solution. You have to see your business in the broadest sense and keep moving ahead with it . Cycles is developing faster than Octane. Indigo was a one man band and moved faster than your team do. Regardless of the trickiness of coding for gpu people have expectations for the rate of development of something.

Well then I'm sorry to disappoint you.

I dont know what you are working on with 2 people for a
year and havent finished but I would think people would be hearing that and asking themselves if it is worth it when there are a list of things they possible could do with already that would not be so involved.

It was 6 months in total and a lot of work went actually into the data handling of the render framework, which eventually made the SDK and the application more robust, but was needed to get the feature working. This feature was a requirement for the cloud solution. And yes it was taking frustratingly long, but that's the way it is sometimes. I hope, people will see the benefits when they get their hands on it.

Anyway, I will step out of that discussion for now. Thanks for your feedback and I hope we will prove you wrong in the future

Cheers,
Marcus

[Zay]

How about displaying only the pin name and making the node name editable in the node graph editor instead?

Sorry for the delay. I use the Node Inspector 98% of the time, so what's in the Graph Editor I will leave to others. I'm fine with leaving the name to either the node or pin name in the Graph Editor.

I for one is very happy to see the progress with Octane since Otoy took over the wheel. Nice to see images of new features coming up and we diffidently can't complain about the frequently updates and bug fixes. Great job!

[pixelrush]

OK thanks for the reply and explanation.
I was beginning to think I might need to travel to Auckland for a wrist wrestle to settle matters.
If you guys take a few moments every now and again to promote your development activities to the community in a general way people will perhaps be a little more understanding of where things are and why.
Unfortunately the baggage of the Refractive era does shadow peoples perceptions.
If people have a place to enter their requests and vote on priorities at least they feel they are participating or have a suggestion box that people might sit down and go through some time. They can discuss things or even bicker and squabble there and it won't pollute the release thread and the reporting you would prefer.
I'd say this is just enabling more deliberate and effective avenues for dealing with different aspects of customer relations.
Both coders and users will be less frustrated by being at odds because they can't satisfy their intent/wishes or aren't on the same page. Overall I have been somewhat disappointed with Octane's progress. I don't think I am alone in that. Otoy are doing better but I think its still lagging behind where it needs to be regardless of the level of difficulty involved. I think that would be a perception prospective customers doing product comparisons would come to as well. Spherical camera being added quickly by Otoy request is nice but that isn't necessarily convincing of an ongoing program of things happening behind the scenes unless you keep people informed of the big picture.
Still its good to have it. Please dont' take it away again because some of us didn't warm to the duplicated names.
Anyway V1.20 sounds good. Looking forward to it.

[cfrank78]

So I guess I am with you - but perhaps in a more gentle
way.

To be honest i really would like to, but my english is so bad, that i have no idea how to write straigt forward whats the point, without writing harsh. The point is that i feel i have a ferrari, that was developed with a diesel motor, because of some of those basic missing features which are essentially for a fast and efficient workflow, especially if oyu have bigger szenes!

I don't understand where is the problem with UV mapping. If you correctly unwrapped your model in your 3D package, it displays correctly in Octane. I used UV mapping since the beginning in Octane and never noticed any problem.

Roubal please have a look at this vid: http://www.youtube.com/v/Thg6k0qpJlo

This is how it should be and is in most other render engines. Compare this with the possibilities in Octane. When i for example render bigger szenes where i combine 3d models from different szenes i wanna be flexible. Every standalone renderengine should have the possibility to change between boxed, planar, x,y,z, mapping and also to reposition the mapping in the render programm itself, without switching back in the 3d modeling application or photoshop. Working like this if i have bigger szenes is a pain in the a.....! I wanna be able to bring 2, 3....50 Labels on an object with just a simple "position" klick, like in the video.

Also - the UV Mapping is only one point from a huge list. There was never a small feedback from the team like "We are on it", or - ok we will do it or anything else. Will it come? Yes/No - nobody knows, and when i am on a huge project like yesterday, i get frustrated. Go to keyshot with bad render results compared to octane but setting up the szene in 1/4 of the time it takes in octane, or do it in octane, take 4 times longer and have better render results. What i would want is the power of octane with the flexibility of keyshot. That would be "professional".

What would octane need to be efficient and a high end professional renderengine IN MY OPINION:

-ctrl (cmd) z
-Completely rebuild UV mapping tools
-adjust camera with numbers that are known from photography - same values for aperture, shutter speed and so on
-correctly implemented 3d mouse mooving, like in the 3d programm itself
-the ability to apply many textures (up to 30 or more) on a single 3d object
-rounded edges
-better working "dirt" map, with better possibilities to apply textures for real looking dirt
-MOST IMPORTANT: applying materials faster with keyboard shortcuts i.e. shift - left mouseclick to copy material and shift right mouseclick to apply same material to another object; ctrl shift left mouse for linking materials - ctrl shift right mouse to unlink, just to name a view options.
-better possibilities than macros, to work with offline materials (offline material database), that is shareable with 3ds max/cinema4d and so on.

Again - this is just my opinion, but these are for ME the most important features that i miss, to work really fast and efficient with octane. Octane is very fast at rendering, but preparing a szene is not very good in the interface.

Kind regards Chris!

[mib2berlin]

Hi Octane crew, as I mention in 1.13 thread, if I switch off one card in preferences and switch it on again the Ms/sec is the same as with one card.
I have to reload the scene to get power of two back.

Cheers, mib.

[ROUBAL]

@cfrank78 : After looking at the Keyshot/Label video, I understand better what you want. This tool is really impressive, but this system implies some important limitations imho : I fear that it would be limited to still pictures, and the fact that textures are applied in the render and not on the original models do not allow to render easily the same project with different render engines is needed or wanted. So, I think that this is probably a hard to code system with usefulness very different according to the user workflow and needs. This said, allowing multiple UV systems would be great, but it may be a Cuda limitation (I don't remember).

@Marcus :

The only thing that is frustrating is that people don't accept that there are features that take little development time and features that take much time.

Thats the reason why I am so surprised that some simple little features (apparently, because I have no skills in coding, but for some of them we have been told a long time ago that they would be not difficult to do) like negative scaling on transform node, have not been treated in priority. I think that treating in a row the simplest little things asked for ages would make happy a large part of the users.

Also some new features come with an important little thing lacking : Fog is a great step forward, but is very dependent of camera parameters. Adding a simple output pin to the camera node for its transform values would allow to chain the sphere object node allowing the parenting of the medium sphere to the camera inside Octane. This would allow to move the camera everywhere without requiring to copy paste the Position coordinates of the camera into the position transform of the sphere each time you move the camera !

It is just one more pin on a node for an already present parameter, and would make the fog feature much more usable ! Without, intead of a pin on a node, it is a needle in the foot for the user !

[smicha]

First - thanks TEAM for your hard work.

Second - front view and back view are switched - I imported obj from 3Ds and sketchup - same results. Please switch these views (front to back, back to front).