I'am an ex ChaosGroup employee and I can tell you that if there's one thing I learned while working there, it's that all these constraints are in your mind. You can find talent here. You can create a product here and sell it worldwide and be successful. You can be competetive or better than your western competition. In some ways, doing this is even easier than in the west. My view is that in order to be greatly successful, you need 3 things, no matter in what part of the world you happen to be:
1. Great idea.
2. Great timing.
3. Lots of work.
(besides the companies you listed, I could also mention coherent-labs.com, which are also global leaders in their market).
I don't live in EE (and maybe I'm naive about this), but shouldn't it actually be easier to find great talent if you put in an effort?
I mean, there are great people in pretty much in every country, and if the alternative is, say, (boring) outsourcing development work, shouldn't you be able to convince people with above average (local) pay and offering them a great place to work, etc?
Nonsense. You’ll make plenty of money by actually building something people will pay for. You know, a product can actually make money without raising VC?
I agree, but then you have to bootstrap with your savings, which means you definitely won't be paying above average wages and renting nice offices etc (which is what I was replying to).
That may be valid only if you're able to raise good money but the tech investing culture is quite underdeveloped here. The startup scene needs several bigger exits to make the investors greedy and curious about it and also construction/private property yields huge profits right now, so the tech startups are not the spotlight catcher.
Without making this sound ridiculous -- sometimes it just doesn't make sense to do tech. If I can make crazy returns investing and/or building property, you should probably be doing property and not tech. EE is probably a good place to be in terms of property investing at the moment.
I've written my own over the past 2.5 years, mostly on the Train to and from work...
Ignoring geometry and texture paging, curve support and volumetrics (all of which I'm slowly working on), it could be used in production.
But then I guess any renderer can produce a pretty picture with physically-based shading - but speed-wise (it's a brute force GI renderer only, no irradiance caching) it's competitive with the other CPU renders out there with similar settings.
The harder stuff is memory-efficiency - Arnold's amazing at this, and numeric stability over all different types of data.
Given the amount of research out there, it's really not that difficult - most of the hard stuff I found was decoupling the GUI (I've written my own context-creation / scene editor as well which hosts the renderer) from the renderer - that involved a lot of re-writes...
Even if you ignore volumetrics and splines, a production renderer still needs tons of features. Gradually adding those increases overall system complexity exponentially as of course new features should not break old ones, and need to be backward compatible (scene format wise) as well. Consider f.e. different sampling types for indoors/outdoors/material wise, handling millions of triangles with limited RAM, subdivision surfaces and sub-surface scattering, many many types of materials your users expect you to support (and precompiled combinations there of), speed expectations etc. That's really just scratching the surface about what's in a production renderer. As they say, the devil is in the details :).
Of course if you render two spheres on a plane, yeah you can write a tracer for that in 10 minutes and even compete with others.
Working in the VFX industry, I'm well aware of what a production renderer needs :)
I wouldn't say adding features increases complexity exponentially - I guess it depends on the design of the system, but that hasn't been my experience with my stuff...
I assume by "different sampling types..." you mean BSDF importance sampling for outgoing direction and sampling the Solid Angle or pdf of taking that direction? If so, I'm not sure I'd call that especially difficult...
Building up ready-to-go materials (certainly as many as Vray ships with) undoubtedly takes time, but in the VFX industry, generally everyone writes their own shaders anyway...
Anyway, my focus is on VFX so I can concentrate on those type of issues, whereas I guess Vray needs to work well across different domains as well (product design, archviz, etc) - that'd be where things start getting difficult to balance out the different requirements I'd assume:
e.g. you can save quite a bit of memory by not storing vertex normals as vec3 floats, but as two 16-bit ushort numbers which can then be mapped via a LUT to the spherical coords of the normal. This is acceptable for VFX, and even in worst-case situations (very zoomed in on a very dense mesh with lots of crinkly displacement), it's barely noticeable, but for archviz people rendering at 10k x 10k, they might spot the issues at that size...
