NOX open source

I saw the news today morning, nice they went OS. Never played too much with Nox.

Still though, i hope one day there will be a really good optionally biased engine around (i mean mostly full featured, not counting Mitsuba for example) open source. Something along the lines of vray/corona/redshift.

Cycles getting more Integrators to choose from would be amazing obviously

Ask Nox is possible to use gpu? and if possible nvidia or ati?

The phrasing sounds like they aren’t interested to develop any more:

After years of development we decided to give NOX for the community

You can freely improve and modify this render engine, integrate it with any 3d software, write plugins for NOX, use it in your commercial works and / or sell it. The possibilities are endless and depend only on you.

And they didn’t setup online source repo, or show commit history of work so far, instead its a 420mb code-dump (though perhaps they plan to setup source control later).

Not to come off overly negative, its just if the original developers abandon the project and don’t bother to hand-off to others, it begs the question why would anyone else be interested to work on it.

Does this have any significant advantages over other open-source ray-tracers out there?

Does this have any significant advantages over other open-source ray-tracers out there?

AFAIK yes.
They have great built-in postproduction system, realtime dof with bokeh, tonemapping, lens effects etc.

Yes the Postfilters in NOX are damn nice!

Yeah, the postfilters of NOX are damn nice!!
The DOF is crazy good

424 MB source holy crap!!! This is going to be interesting to look through.

I quote every single word. And to not throw out of the window what blender devs did until now, I hope me too that Cycles will give us some biased rendering method

If only it were as easy as an “add bias” option. Being biased and using the same physically plausible material system is arguably even harder than creating what Cycles is today.

If you consider many engines shares material system within different integrators i wouldn’t bet that would be the problem. Given an experienced coder works on it, making a third integrator which solves GI with interpolations is nothing exotic from what i got from different trusted devs when i asked about it, special treatements for glossy and bumps if i remember, but nothing that it hasn’t been very well documented.

Of course no GPU and no interactive viewport, but we could mix the two integrators for example (shading with PT and GPU, test renders and finals with Light caching et similar…) At least for certain fields i mean…animations / vfx would make little sense, but Cycles would embrace a LOT of new user cases, a full featured, open source, optionally biased engine with nodal system, there aren’t around.

The only problem i see is “just” nobody is going to work on such topic, paid or not. BF core dev neither as pointed in the ML list. Then just dreaming.

Looks like the license is Apache 2.0, does that mean we can borrow some of the code for Cycles then?

If so, it would be nice to adopt some of their optimization techniques that we don’t have yet, especially in the area of sampling.

The only thing might be is whether it’s just a massive code dump or the guys at Evermotion made or will make an effort to document the structure of the code and how it works (as the former will make it difficult for prospective developers to start working with it).

Skyportals, IES, displacement and Bi Directional integrator are nice ones that Cycles lacks imho, but i doubt they can be translated easily :o

Yep, but as @marcoG_ita says, it’s unlikely a simple translation.

Checked the code its ms-windows (MSVC C++) only.

So far only had a quick check on the code, but seems its using well known raytracing methods

Looks like not much effort went into the release - DLL’s EXE’s all over, multiple versions (paths such as MaterialEditorUseDLL/old shit release/asdf, MaterialEditorUseDLL/Backup/MaterialEditorUseDLL, ./MaterialEditorUseDLL/… make this look like a dump of someones working files.

Sure, the feature list was impressive; but Nox is just SO. SLOW. I really liked playing with it each time there was a new release, but I never used it seriously because renders just took far, far too long. I can’t help but imagine it would have made much more of a splash if it had been quite a bit faster.

there are some nice features, like being able to adjust exposure during rendering, and crunching away fireflys is awesome. much more satisfying than merely clamping values, as with cycles; but then there are features that totally ruin things like adding depth of field adds another hour 1/2 onto an already extensive render time, and as there is no preview, if you get it wrong then you have that long assed cpu hogging wait all over again! nasty :frowning: also there is very little documentation to go with the program, the current PDF is out of date and refers to things that are no longer applicable, and the layout of the ui has changed too judging from the document. so if you aren’t sure of something it is quite a bit of trial and error to figure out, like reflective surfaces, i spent ages trying to figure out how to create metallic object and only got it going by using a random metal from the NOX material library, and still cant see what the difference in settings are!

having no procedural textures is somewhat awkward too, an area in which cycles positively shines. so it’s either just rely on image textures or set up procedurals in cycles (or BI) and bake everything that you need beforehand, but if your going to go to the trouble of setting all that up you may as well just use cycles in the first place, especially if you have a slow pc and baking is going to add a further couple of hours to your time. overall, the reults are really nice but i don’t think they are nice enough to be worth the extra time you would save just using cycles.

however if the dev’s do keep plugging away at it it could be a very practical alternative to cycles for when you need a certain look. though i doub’t it will ever match cycles for speed unless they decide to integte GPU rendering.
just some observations, your machines may handle it better.

I am not absolutely sure, but as i currently stilll trying to makle MCMC render in my “volumetric” patch to sux less for average scene (it good for hard light scenes, but 4x or more slower for typical almost direct light), i have some experience how MLT/MCMC bugs looks. And after looking NOX gallery, first thing i notice it seens make biased image, pulling too many lights at very bright area (i repeat, i can be wrong).

Still, NOX use true Veach MLT (mutations strategy that a bit more complex then Kelemen used in pbrt, Luxrender), that alone is huge feature, too bad it not multi platform, i have no windows developer tools around to try compile it. Definitely it worth to play with, and if i wrong and they have no bias in MLT, adapt it to Bleder.

I think, NOX is an open source development platform for C+±based software-defined networking (SDN) control applications. POX, a variant for Python development, is becoming more commonly used than NOX.

i have no more idea about that. i also want to know more about this open source.

So has there been any development at all on the NOX engine in the past month or did it seem like too much of a code dump to do anything with it?

If the latter, it’s sad to say, but more often than not you see FOSS seemingly using the popular ‘Corrupt a Wish’ game as a development guideline (unlike the majority of cases with commercial solutions)