How rendering should be
Re: How rendering should be
And this is the consequence of having an ICE-centric development. Time passes and SI cant keep up with even open source softwares in terms of performance and daily normal operations, not to speak about rendering. And things arent going to change since SI is officially a maya plugin now.
Re: How rendering should be
For a small story, while ago it was a feature called 'open gl shadow map acceleration', or like. By enabling this, it was possible to get a faster shadow map, accelerated by GPU. For small price of memory leaking, whatever graphic card was used. About twenty frames, then only re-start pf machine for another twenty. I think I've tried it with every possible graphic card, including pro ones... MR "feature" was removed in XSI 6, I think.ActionArt wrote:Is that ever true. There's been features handed to them, just sitting there for years that haven't been implemented. Can't imagine how it would change though. MI/Nvidia isn't going to do it for them.Kzin wrote:xsi implementation depends to much on ad at the moment, i hope this will change soon enough.
And THAT is main problem, instead of fixing, there is always a new set of magic words. Once the new magic doesn't work, there's a time for a new round.
Only alive MR implementation beside AD, seems to be Mental Ray for Cinema 4d. Not that much of traffic on their forum, especially compared to one of sites of V-Ray for Cinema. I'm wonder who is guilty this time...
Re: How rendering should be
These sort of features never made any sense to me. Shadow map acceleration? Why accelerate something that's already fast? It's like the current AO pass on the GPU. Who cares? It's already the fastest part of rendering passes. Why not accelerate something that is painful slow now like volume rendering, area light shadows, final gather pass etc.
Iray is getting a lot of development but still no implementation which IMO is just silly. It seems it could be a great visual feeback tool far more useful than the current HQVP.
Iray is getting a lot of development but still no implementation which IMO is just silly. It seems it could be a great visual feeback tool far more useful than the current HQVP.
Re: How rendering should be
area light shadows will be alot faster because of the new importance sampling in 3.11.
working more on fg makes no sense at this stage. ;)
volume rendering is a shader thing. what mi could do is code a general one, but its to custom i think because in vfx alot of shops use their own stuff. in the meanwhile, take a look at emfliud and the ba volume shader which is voxel based.
i agree on iray, alot of users using it for fast previews but progressive rendering would do the same.
ad has stated that they are not interested on iray integration in si.
i dont know what the decisionmaker ad ad thinks about the hq viewportstuff when you have no connection to the current renderer, i dont get it. it would make more sense to integrate iray, especially if you want a future proven solution. but also here, ad stated that the users wants such a solution.
working more on fg makes no sense at this stage. ;)
volume rendering is a shader thing. what mi could do is code a general one, but its to custom i think because in vfx alot of shops use their own stuff. in the meanwhile, take a look at emfliud and the ba volume shader which is voxel based.
i agree on iray, alot of users using it for fast previews but progressive rendering would do the same.
ad has stated that they are not interested on iray integration in si.
i dont know what the decisionmaker ad ad thinks about the hq viewportstuff when you have no connection to the current renderer, i dont get it. it would make more sense to integrate iray, especially if you want a future proven solution. but also here, ad stated that the users wants such a solution.
Re: How rendering should be
I was just thinking of Weta's use of GPU acceleration for area lights on Tin Tin. Looks like Nvidia had a big part in it. That would be useful but highly unlikely it will be a part of SI in the near future.Kzin wrote:area light shadows will be alot faster because of the new importance sampling in 3.11.
I have. So far they're not what I was hoping for and certainly not fast. Also (for me) very confusing and difficult to set up. Volume rendering just seems a natural fit to use the GPU on. I haven't tried the new Fury yet so I will at some point.take a look at emfliud and the ba volume shader which is voxel based.
Progressive is still CPU based though and not exactly fast. In Blender with Cylcles the GPU mode is blazing fast in the viewport even on a old GTX285 like mine. I find it very aggravating that AD doesn't want to get Iray going in SI.i agree on iray, alot of users using it for fast previews but progressive rendering would do the same.
ad has stated that they are not interested on iray integration in si.
I guess I should make it more clear too that I don't mind MR in the final render process, in fact I rather like it as it's so flexible, it' mainly the working and preview area that bothers me the most and the fact that a solution is sitting right there (Iray) and all they have to do is hook it up is the most maddening part.
Last edited by ActionArt on 21 Aug 2012, 05:22, edited 2 times in total.
Re: How rendering should be
The reason why AD doesnt want to implement iRay is mostly due to the work behind it, as it was said many times, taking care of a render engine is quite a job and effort, i have no idea who is now set to this task but the development of Softimage is all focused on ICE, i cant see them swapping time/development/resources/money into taking care of the rendering, this never happened since quite a while, and this is the reason why we are at this mess now.
They rather focus on adding ICE nodes than havin the render engine works properly and with all the features. Not counting that the implementation from AD always lacked of many things, and came also with wrong default parameters which was never fixed, showing quite the lack of knowledge by them on Mental Ray. Reason why who develops a render engine should also be in charge to implement it. But this is another story, AD found on their hands a product they were totally unaware how it works, and it showed by implementations trough those years.
Dont expect to see any news on Softimage rendering anytime soon, AO in gpu? its gonna end up like iRay, not implemented and so on. Bottom line, they dont care about Mental Ray anymore, i am pretty sure in Beta testing no one uses it anymore. Also might as well fix the framebuffer before even attempting to implement something. Those are things and problems that are going on since years and never addressed. There is only one reason for this, they dont care. There is no excuse for some of those things not to work not being integrated, not being fixed after all those years. But hey, they keep taking ur money.
Nice job with the HQ viewport.
They rather focus on adding ICE nodes than havin the render engine works properly and with all the features. Not counting that the implementation from AD always lacked of many things, and came also with wrong default parameters which was never fixed, showing quite the lack of knowledge by them on Mental Ray. Reason why who develops a render engine should also be in charge to implement it. But this is another story, AD found on their hands a product they were totally unaware how it works, and it showed by implementations trough those years.
Dont expect to see any news on Softimage rendering anytime soon, AO in gpu? its gonna end up like iRay, not implemented and so on. Bottom line, they dont care about Mental Ray anymore, i am pretty sure in Beta testing no one uses it anymore. Also might as well fix the framebuffer before even attempting to implement something. Those are things and problems that are going on since years and never addressed. There is only one reason for this, they dont care. There is no excuse for some of those things not to work not being integrated, not being fixed after all those years. But hey, they keep taking ur money.
Nice job with the HQ viewport.
Re: How rendering should be
No kidding. MR will do a half ass job of developing it and AD will never get around to implementing it.Maximus wrote:AO in gpu? its gonna end up like iRay, not implemented and so on.
Whether AD likes it or not, Iray is getting the Lion's share of the effort at MR so if they had any sense they'd get with it.
The only way AD will start to care is if competition (especially free competition) leaves them in the dust. But they won't notice or care until several years later...if then.
Not for long.But hey, they keep taking ur money.
Re: How rendering should be
i understand that gpu rendering is what people wants but keep in mind that mr is for vfx work and gpu is not that flexible then cpu rendering at the moment. because of that, mi goes 2 ways, mr and iray for the moment. there are developements to get over the problems on gpu, so lets see what the next years will happen.
and i dont think gpu rendering is much faster. i am playing aroung with octane render, its great and fast for what is does, but 1080p noisefree renders also take 8-20 hours on my gtx580 for more complex lighting situations.
wetas pantaray solution is complete different. weta renders all the arealights with pantaray, bake it and using this as lookup in renderman. so they using 2 renderer, with renderman a custom solution with all their stuff. i think that only works in a bigger pipeline. i cant imagine how this would help me for example to get faster results. it would be a mess to work with such tools for smaller shops. the interesting thing with pantaray is the amount of data it can handle on gpu. i am pretty sure something like this will find its way into iray. the last update goes more in the production direction. i know it would be great to have this in mr, but at the moment other things have more priority because they are more critical (the whole flexible bsdf stuff and the gi).
ad dont know what to do with mr, thats true. its a big problem and i dont know how this will end.
the alternative is to get string options as soon as possible for xsi so ad dont have to do that much in the future and the user can use the features he wants.
and i dont think gpu rendering is much faster. i am playing aroung with octane render, its great and fast for what is does, but 1080p noisefree renders also take 8-20 hours on my gtx580 for more complex lighting situations.
wetas pantaray solution is complete different. weta renders all the arealights with pantaray, bake it and using this as lookup in renderman. so they using 2 renderer, with renderman a custom solution with all their stuff. i think that only works in a bigger pipeline. i cant imagine how this would help me for example to get faster results. it would be a mess to work with such tools for smaller shops. the interesting thing with pantaray is the amount of data it can handle on gpu. i am pretty sure something like this will find its way into iray. the last update goes more in the production direction. i know it would be great to have this in mr, but at the moment other things have more priority because they are more critical (the whole flexible bsdf stuff and the gi).
ad dont know what to do with mr, thats true. its a big problem and i dont know how this will end.
the alternative is to get string options as soon as possible for xsi so ad dont have to do that much in the future and the user can use the features he wants.
Re: How rendering should be
Yes, cycles is nice too, but is half baked, and many features are not implemented and are only beta (i. e. cycles cannot rendering particles). Actually you can have fast result with GPU, but the big development is under CPU, and they will have, in a year, a fast rendering CPU without memory issue (GPU will be used, if I understood correctly, only for preview purpose), blender developers affirm GPU development is too complex and with too many limits so they started from the beginning cycles like a hybrid cpu/gpu. The viewport preview is very fast (IMHO many steps forward for quality and speed than HQV) , but in opengl is very poor, they have a google summer code project (a totally new rebuild of opengl code for the viewport following the new opengl 2.0 standard) and in blender 2.65 viewport FX will be ready to rock.ActionArt wrote:I recently tried Blender briefly along with Cycles and I now feel we're in the stone age with rendering in SI. I dread learning yet another major ap but it sure seems tempting so far.
I imported a large .obj file and it loaded in about 1/2 a second (SI took over a minute). The viewport seemed at least as fast as SI and rendering was a joy. I will be investigating further, but it's pretty impressive. They're gaining ground fast.
What disappoints me most is SI could have easily had something similar with Iray but instead wasted their time with this wretched HQVP. I've tried many times to use it but it's utterly useless. The scene translation or whatever it's called is so slow it's laughable. It would have to be 50x faster to be any use at all.
I think blender must be respected, sometime I read caustic or hilarious comments about, many think it is not at par only because is free, or the common thought about blender is a not well implement software due to his open source nature where anyone can put his hands for adding this or these other feature. All wrong, blender is one of the most coherency e well structured software out there, his development beginning before maya, and has different paradigms, but it far different from agglomerate plugins like 3dsm because blender foundation has a strong control all over the process (and the process going fast and strong like a train)
I astonish about how fast and user friendly is blender development (and all they are free users...)
Officially Maya plugin? Are sarcastic or is a reality?And things arent going to change since SI is officially a maya plugin now.
IMHO the idea of selling softimage with maya was a good idea (I prefect understood is a open woods in every xsi user pride)
Re: How rendering should be
I think that SI future is more guided towards game industry, same as Maya (look new DX11 viewport), that is reason why HQ viewport was built. It is not important what render engine you have the most important thing is to have viewport similar as possible to game engine output. I think that SI is now oriented to eastern market, and as far as I am familiar with that they use SI mostly for creating gaming assets, correct?
So I am not big optimist with MR and SI also.
So I am not big optimist with MR and SI also.
- H -
-
- Posts: 143
- Joined: 09 Jun 2009, 12:12
- Location: Czech Republic
- Contact:
Re: How rendering should be
well, i think it's a good thing that SI team doesn't spend too much of it's limited resources on Mental Ray. Almost all SI studios I know already use Arnold or Vray or 3delight. So it's better to focus on other things and let these 3rd party developers take care of rendering, have instant support, many releases and fixes within a year etc.
I know that many freelancers can't get access to Arnold, but Vray looks promising as well and I believe version 2 will be really good with RT and volumetrics... There are several gpu renderers available too if you are into that kind of stuf... So who cares about MR?
I know that many freelancers can't get access to Arnold, but Vray looks promising as well and I believe version 2 will be really good with RT and volumetrics... There are several gpu renderers available too if you are into that kind of stuf... So who cares about MR?
Re: How rendering should be
I said something similar on MR forum, about most of studios using other render engines with SI nowadays ... man I almost finished in jail ... So take care about what are you saying
- H -
Re: How rendering should be
The main problem with switchin from MR to another is the time you invested in it, the fact that you are forced to buy another product from a company that doesnt give a damn about updating things they have implemented. We are talking at boundaries of logic here.
You dont give a damn about MR? Beta testers dont use MR? You dont update MR? Fine, just remove it from the software and cut down the price.
Its not a matter of days to switch to another render engine despite the frustration you will have cause you have to learn everything again, especially when you encounter problems.
Also the fact why no one uses MR anymore in SI is also an AD fault, not Mental images one, If the engine was implemented perfectly 100%, i bet more people would use it.
You dont give a damn about MR? Beta testers dont use MR? You dont update MR? Fine, just remove it from the software and cut down the price.
Its not a matter of days to switch to another render engine despite the frustration you will have cause you have to learn everything again, especially when you encounter problems.
Also the fact why no one uses MR anymore in SI is also an AD fault, not Mental images one, If the engine was implemented perfectly 100%, i bet more people would use it.
Re: How rendering should be
Volume rendering can be very memory intensive, especially if you're rendering several different types of data (density, temperature etc.), so maybe not so suited for the GPU?ActionArt wrote: I have. So far they're not what I was hoping for and certainly not fast. Also (for me) very confusing and difficult to set up. Volume rendering just seems a natural fit to use the GPU on. I haven't tried the new Fury yet so I will at some point.
Re: How rendering should be
perhaps we should be more exact here, which users switched and why? which jobs they have to render? which renderer they are using now?Maximus wrote: Also the fact why no one uses MR anymore in SI is also an AD fault
problem is that everyone is writing this without to give some more infos.
Re: How rendering should be
you throw in a general statement from your limited view which is not true at all and you was corrected ( btw, i did the same experience for the people i know).SreckoM wrote:I said something similar on MR forum, about most of studios using other render engines with SI nowadays ... man I almost finished in jail ... So take care about what are you saying
problem is that you dont awnser anymore like alot of people which comes in the forum, bash mr and goes away. dont know why they dont defend their meaning. if you write this, name the companys, what they do and WHY they switched. thats the important point, the WHY. the mi developer reading this forum more often then you think, they discuss about it. but that all makes no sense when you wrote a simple line of words which helps no one.
mr sucks? why it is sucking. ;)
Who is online
Users browsing this forum: No registered users and 15 guests