OTOY Forums

I wonder what is Otoy's policy on getting a refund for plugins, or possibly exchanging licenses for a different plugin. I mean, there is an software activation process, so it isn't like I would get to keep two licenses but only pay for one, right?

Should be possible, but i want a fully working DAZ Studio plugin. I don't want to use Poser anymore, DAZ Studio has just too many advantages in daily use for me. The last update from T_3 fixed a lot of things, but after weeks and weeks looking each day for the promised next update.. things would be a lot easier if the developer would post a statement.
And noone can be too busy to watch this forum once a week.

The major and root problem for this delay and slow update is they literally don't have any competition in this market AT ALL.
There is nothing that can draw Otoy's attention of a potential loss of customers in any circumstances.
Even if you refund this plugin, you will go buy the other one like Oct for Blender or 3dsmax because this is the only Good, fast GPU render which supports Nvidia Cards.
Imagine one day Luxrender announces that Nvidia GPU boost is now fully supported and all bug is fixed, and the render time is around 1-2 hours longer than Octane render, then this forum may officially pronounced dead at this time.
It is now US begging to have a new update on the plugin, not that THEY begging us to stay, they don't really care because in the end you will still buy one of the other plugins.
No one wants to lose a piece of market, but the ignorance only happens when you have the full market and no one is challenging it (which is called monopoly).

Hopefully we can get some updates soon, still sticking with 1.2x and trying to apply those Redspec TGX to the 1.2x version.
Does anyone want to file a official complain to Otoy with reference to the local law? (Like fraud advertising, unfinished product, No contact with customers) and demand a response? Or the next new update might be an Easter present, if not Christmas present

ATM there isn't an alternative but the recent release of Indigo Render for iClone 6 is very encouraging. iClone Pro 6 and IR cost $299. That's significantly cheaper than just the OR standalone! I wonder if Indigo has any plans to support other low end software like DAZ Studio or Poser? I'm not a fan of iClone or suggesting we all crossgrade but the results look pretty good and I wonder how quickly IR renders compared to OR?

Out of curiosity's sake and for my own knowledge of options, I'll try to do a comparison of the student edition Octane for Blender vs. Indigo trial for Blender (I figure the student edition being 1.2 should roughly equalize the probable hobbling in the trial version). I'll let you know what I come up with.

Edit: I'm thinking the weak link in my plan may have been trying this in Blender. Each uses a different version (Octane's installing it's own, while Indigo recommends a newish one and links to the newest), and Blender itself isn't necessarily the most intuitive interface I've seen (brick wall, anyone?). However, the test kind of got shot in the foot when I couldn't really get Octane to render anything (though it reported it was), and Indigo I could get to render, but couldn't for the life of me figure out how to edit the materials to be recognized aside from the light materials I downloaded from them for use (which did look fabulous, for the record), so it was all basic white textures. Given that I would consider it a simple scene I've repeated numerous times (standard g2f with a light clothing set and three panel lights inside a cube to simulate a room), I would rate the speed of indigo at pretty close to Octane 1.2 (the standalone, with plain white mats and simple lighting), at least as far as I can tell given the limited scope of my Blender abilities.

Personal thoughts: Indigo itself seems better documented, though not necessarily for how to use it with Blender, it does have a section, but it wastes too much space on unnecessary images of things that are duplicating the things in Blender's own docs. I would consider the speed comparable, but would hope that better integration occurs at some point for both. Octane in Blender is typically cryptic, and while Indigo seems more open, it is far from intuitive itself, and from what I can tell, only renders in it's own separate process that is called when told to render (which is sort of the same thing as exporting and using Octane standalone, which if we're counting newest versions, is markedly faster (by a lot).

I will say, I was rather impressed with Indigo, and it is by far the better documented of the two, but shares the same (or similar) integration weakpoints as Octane, and seems at least a little slower than the newer Octane. I'm positive if I had just imported the .obj into the standalone, I would have had my scene rendered in less time than it is taking me to type this, and likely in less time than it took me to figure out/look up how to get materials that function for each renderer to get applied to objects in scene (which apparently I missed an important step somewhere for regarding Indigo, and couldn't get the Octane one to actually display, regardless).

For whatever help that may be to anyone, lol.

Thanks for trying sikotik13. It must be very difficult to compare two different renderers in Blender which is not the most intuitive 3D software. I found this comparison from late 2012 so it's pretty out of date but compares renders from Octane, Indigo and Maxwell:

http://www.indigorenderer.com/forum/vie ... =4&t=11814

I think I prefer the Indigo render as it's richer in colour and appears more "realistic" than the others. Although the colour in the others could be addressed in post.

True, and as addressed in one of the later posts, he adjusted colors for each renderer, so likely a lot of the tone differences are the poster's fault. Or at least, it's impossible to determine where the fault lies, exactly.

I will say that from what I could see (and I think we all at some point rendered something without textures {*cough-whentheprereleasewasdroppingimagemaps-cough*}), Indigo did look just as good as Octane, just rendered at a little lower speed, but that may have been a setting I didn't adjust, or is locked in the trial version. I attempted to not alter anything other than install, apply some sort of light material to the panels and render, since theoretically, those steps at least should be nearly identical regardless of the middle software used (or they would be for me, anyway), so I didn't go deep in options for either renderer, and spent the majority of time fighting the interface of Blender. For all I know, Octane implementation in Blender has improved a thousandfold since 1.2, and it appeared much better integrated, I just couldn't figure out why it wouldn't show me the render it was telling me at the top was rendering at 71.9M samples per second or whatever (yes, it claimed that, I have no idea as I couldn't view any output). If it was true (and I doubt it), that was certainly faster than Indigo, but judging solely off of looking at the Indigo render as it progressed, I am confident in my comparison to the first few things I tried direct exporting to OcSA 1.2 for speed.

Again, that is without altering anything in either renderer, so no optimization, and clearly not properly applied materials, so in my mind, once one got over the hurdle of material set up, they should be relatively close-ish. It's mostly the idea of learning an entirely new workflow, or adding another program on top of my preferred program into my current workflow. At which point, I may as well just go back to exporting to Octane standalone, since at least I already paid for it. I'd rather progress just get made on the plugin I also already paid for, since you know Otoy is all about how they "go above and beyond" to support plugin developers... Maybe one will actually read this thread if I figure out how to type that sarcastically enough.

I would hazard to guess that if any of the programmers had spent half of the time reading through Daz API as us regular posters have spent posting workarounds/suggestions/apologies for missing features, they could probably re-write it from scratch. Which, to me, says no one is bothering to do anything about helping t_3 because no one at Otoy is either a.) smart enough to figure out the insanely complex program known as Daz Studio, b.) anywhere near as helpful to developers as they like to claim. Perhaps both. If the help is soooo incredible, why is there one plugin (just one), so far behind the rest? If the rest are all caught up, and the developers all have equal rights to this help, logic dictates the only one struggling to keep up should probably be receiving the bulk of it. Or, you know, at least have someone keeping tabs on what's going on enough to pop in and let us "privileged" beta-testers know what the heck is going on with the beta we keep not getting updates to test.

Just saying.

All of what you say about the contradictions of the development process I agree with. I just can't understand how it's reached this point. I would love to believe that the next release will be the final one but this doesn't seem plausible based on past experience. Has anyone been reporting bugs in this release via t_3's preferred method and has there been any response? I can't see how any of these bugs can be ironed out without feedback and then further interactive testing. Maybe a select group of forum members have been carefully chosen who are in contact as I write? If so I wish they'd reassure us!

If you go to NVidia and download the sdk you can actually find working C++ examples of the very engine used by Octane. Before I bought Octane, I had reality/luxrender (super slow). I was in a pinch so I took one of the source examples by NVidia and injected my model and material reference and compiled it...I was blown away how fast it rendered. Of course it lacked functionality, however was all the proof I needed to purchase Octane. I also took an online course at MIT for computer graphics whereby we had to write an OpenGL rendering engine from scratch. I then took a deep look at reality3d to see how Pablo was passing the data to luxrender. I was convenced I could create my own interface to pass the data to the NVidia's source code engine, thereby bypassing Octane altogether (I still am).

The problem is, how much time will it take to build in all the features we need to successfully render animation directly from Daz? As you pointed out Daz is a very poorly supported program (in terms of documentation). It seems like an impossible task, so I opted to wait for someone smarter, with more resources and time to solve the problem. I'm starting to think that the problem with all of these plug-in for octane (blender, C4D, daz, etc.) is that in order to pass the objects, materials, lights from one program to another is where everyone gets stumped. Reality, for instance, reads the objects, materials, and other settings then writes them to a flat file where luxrender can find it and then carries out it rendering process based on that file. Why not do the same but then have Octane pick up that file and run it??? because the settings are not labeled the same (or formatted the same) so you would have to spend a lot of time figuring out how to handle a daz light and save it so that Octane can render it properly.

Think about materials, how do you set up Daz basic material setting to instruct Octane to use a fractal texture or SSS, or emitter with an image texture...this is why the interface you see now does not match the materials or lights in Daz, its basically impossible (or at least too difficult for even the Octane developers to figure out). I also think that just about all these other plugins operate in the same way. There simply is no standardization for these options that we need. Alembic, which I've used with varying degrees of success, seems to be the answer. Daz has an alembic exporter which works great (even handles motion blur), but it doesn't export camera making it useless. If we could get those developers to export the camera information, we'd have another solution, we could simply forget about all these bugs and set up the scene in Octane - Right?. You can export the scene through the plugin and the alembic, however the problem is when you import it you get a rats nest of incomprehensible nodes and links.

There's got to be a solution in all this somewhere. I mean seriously, what do we have to do? Grab pitchforks and torches?

By the way, blender has an exporter which works pretty good and its free (its not a real-time plugin), I think because the licensing insists they have some sort of free/opensource solution. Anyhow, I'm not saying everyone jump to blender...its just an option that is economical and viable. You can decide for yourself. And for those of you freaked out by the blender interface, in user preferences you can switch the mouse from right click select to left click select (like 99% of every other program on earth) and it makes a lot more sense to use.

Good luck, I'm glad to see everyone taking action. Maybe stirring the pot a bit will get some results (or all of us kicked off the forum).

sikotik13 wrote: I may as well just go back to exporting to Octane standalone, since at least I already paid for it.

I enjoy setting up the scene in a conveniant way and editing materials in the OcDS plugin that has a lot of helpful features for the scene building and material editing stages of any project. As far as I know OcDS has a lot of unique features like the Texture Tab to resize maps that you will not find in any other plugin.

Nevertheless the final step of any project I experimented on in the last month happened in OctaneRender standalone.

- - -

To me it seems that Otoy did invest time to make working in the standalone more comfortable. Especially the latest camera features added in 2.21 will make the standalone a more familiar place for OcDS users.

OctaneRender™ Standalone 2.21.1 - updated

http://render.otoy.com/forum/viewtopic.php?f=33&t=44704

- - -

In addtion while working with OctaneRender standalone I discovered Phantom Scatter a very helpful plugin that offers a lot of interesting ways to work with instances:

http://guusthissen.nl/scatter/

- - -

There also are a lot of lua scripts specifically designed for the standalone that offer a lot of new options how to work in a time efficient way:

Lua Scripting

http://render.otoy.com/forum/viewforum.php?f=73

- - -

The more time I spent with a plugin to standalone workflow the more I realized that this actually offers a lot of new opportunities and alternative ways to solve some creative challenges.

- - -

From that point of view the delay with the plugin update was the best thing that happened to me.
I would never have had the motivation to try out the standalone and would have missed out on learning a lot of new techniques how to work with nodes on a scene level.

Going along in the vein of transitioning to using the standalone;

In the interests of changing my workflow as little as possible, how are the Octane export functions in OcDS?
Specifically, is it viable as an alternative to just using the Daz Studio standard exporter, or would I be better off just going back to basic setup then using the standard exporter, then handling all material settings and such within the standalone? Honestly, ignoring the camera itself, since I never really had a problem with navigating it even in 1.2 standalone (for non-animation purposes, since I still struggle with some of the more basic requirements to make animation look good to me in general), is it still viable to do the previewing and material setup in OcDS to export a nearly complete idea, or will I need to get used to rebuilding materials from scratch anyway?

On that same tangent, it was before my time, but I seem to recall seeing posts regarding an exporter that was being developed before the plugin became the focus. Perhaps that should be reconsidered as a viable alternative, or at least more emphasis placed on the export functions available so we can at least get something done with this currently barely functional plugin thing.

While I realize it isn't necessarily a fair comparison, this really feels a lot more like a game in pre-alpha stage than a beta, since a beta usually requires a decent degree of stability and generally just lacks optimization and usually some specialized features. Most alphas I've been involved with seem far more complete than this plugin, and even 1.2 felt more stable than these version 2 pre-releases. Granted, those have usually been in the game arena, where a non-functional product doesn't do anything but crash (sometimes the entire computer), but the principle seems the same, and generally, while in a non-finished state, the developers spend nearly as much time collecting and responding to feedback as they do actually working on the code. I had gathered this was the entire point of a beta, since one could self-check one's own code endlessly without ever showing to another person indefinitely if one didn't desire the feedback in the first place. In my mind, that makes the entire point of releasing something in an unfinished state to gather said feedback, so this really feels like a peek into a proof-of-concept, not a "nearly complete" pre-release.