While I'm super impressed with how fast Octane is rendering frames -- the load times are KILLING the potential productivity. I realize this may be a technical problem that is standing in the way Face, but if I could suggest one thing that would immensely help rendering animation Octane, it would be getting data handshaking time down to something reasonable. Sometimes I spend 5 minutes(or more) exporting and loading a frame, but it renders in less than a minute.
Is this something on your list of improvement? I realize you've already made quite a bit of progress, because load times are better than they were before -- but still very slow if you're working with lots of geometry.
Let's talk about load times.
... quoting radiance a substantial better voxeling performance is already on the list of upcoming improvements for beta 2.6 - what will result in a notable better loading time for large poly scenes. and as soon octanerender "native" plugins become available, the whole exporting/importing process will be cutted to 0. so the only thing for you to hope is, that a xsi plug is in the works...adrencg wrote:While I'm super impressed with how fast Octane is rendering frames -- the load times are KILLING the potential productivity. I realize this may be a technical problem that is standing in the way Face, but if I could suggest one thing that would immensely help rendering animation Octane, it would be getting data handshaking time down to something reasonable. Sometimes I spend 5 minutes(or more) exporting and loading a frame, but it renders in less than a minute.
Is this something on your list of improvement? I realize you've already made quite a bit of progress, because load times are better than they were before -- but still very slow if you're working with lots of geometry.
„The obvious is that which is never seen until someone expresses it simply ‟
1x i7 2600K @5.0 (Asrock Z77), 16GB, 2x Asus GTX Titan 6GB @1200/3100/6200
2x i7 2600K @4.5 (P8Z68 -V P), 12GB, 1x EVGA GTX 580 3GB @0900/2200/4400
1x i7 2600K @5.0 (Asrock Z77), 16GB, 2x Asus GTX Titan 6GB @1200/3100/6200
2x i7 2600K @4.5 (P8Z68 -V P), 12GB, 1x EVGA GTX 580 3GB @0900/2200/4400
Here is a log i have made to show which times are used for specific data operations.
The testmesh was a textured sphere with 1mio tris.
// INFO : initializing: 0.0265087
// INFO : Vertex access: 0.0162558
// INFO : Vertex writing: 0.341689
// INFO : Normal access: 0.19016
// INFO : Normal writing: 1.39654
// INFO : Texture access: 0.0439852
// INFO : Texture writing: 0.936423
// INFO : Faces access: 1.00283
// INFO : Faces writing: 1.66027
// INFO : Cleanup: 0.00195059
// INFO : Overall: 5.62907
The faces used the most time because i need access to the indices which polygon use which vertex-,normal- and texture-index.
All in all you see, to write in the file is the bottleneck. Not the writing itself, but the time to convert the values to a writeable text format.
I have spend much time to find and integrate an alternative method which is faster than the standard method.
To seperate the process in multiple threads makes in my eyes not realy sense because on 4 cores i would maximum save the half time. To this time, the time to manage the treads will be added, so that you have maybe a plus of 1sec. per 1mio tris.
Another time killer is to uptade the progress bar. I think i have minimized the output of information so that, at this point, there is no more room for play with.
For around 2mio tris i need around 10sec to export. To import it in Octane, i need 40sec.
It´s also on the Octane side to optimize some things and this is not my bussiness...
face
The testmesh was a textured sphere with 1mio tris.
// INFO : initializing: 0.0265087
// INFO : Vertex access: 0.0162558
// INFO : Vertex writing: 0.341689
// INFO : Normal access: 0.19016
// INFO : Normal writing: 1.39654
// INFO : Texture access: 0.0439852
// INFO : Texture writing: 0.936423
// INFO : Faces access: 1.00283
// INFO : Faces writing: 1.66027
// INFO : Cleanup: 0.00195059
// INFO : Overall: 5.62907
The faces used the most time because i need access to the indices which polygon use which vertex-,normal- and texture-index.
All in all you see, to write in the file is the bottleneck. Not the writing itself, but the time to convert the values to a writeable text format.
I have spend much time to find and integrate an alternative method which is faster than the standard method.
To seperate the process in multiple threads makes in my eyes not realy sense because on 4 cores i would maximum save the half time. To this time, the time to manage the treads will be added, so that you have maybe a plus of 1sec. per 1mio tris.
Another time killer is to uptade the progress bar. I think i have minimized the output of information so that, at this point, there is no more room for play with.
For around 2mio tris i need around 10sec to export. To import it in Octane, i need 40sec.
It´s also on the Octane side to optimize some things and this is not my bussiness...
face
Win10 Pro, Driver 378.78, Softimage 2015SP2 & Octane 3.05 RC1,
64GB Ram, i7-6950X, GTX1080TI 11GB
http://vimeo.com/user2509578
64GB Ram, i7-6950X, GTX1080TI 11GB
http://vimeo.com/user2509578
Cutted to 0 isn´t correct, the access times will be needed, also the time to process the data and send they to the GPU.t_3 wrote: ... quoting radiance a substantial better voxeling performance is already on the list of upcoming improvements for beta 2.6 - what will result in a notable better loading time for large poly scenes. and as soon octanerender "native" plugins become available, the whole exporting/importing process will be cutted to 0. so the only thing for you to hope is, that a xsi plug is in the works...
face
Win10 Pro, Driver 378.78, Softimage 2015SP2 & Octane 3.05 RC1,
64GB Ram, i7-6950X, GTX1080TI 11GB
http://vimeo.com/user2509578
64GB Ram, i7-6950X, GTX1080TI 11GB
http://vimeo.com/user2509578
this is of course correct. but without the need to write and read to/from disk (and to do some transformations which are needed to do this), it'll still make a big difference...face wrote:Cutted to 0 isn´t correct, the access times will be needed, also the time to process the data and send they to the GPU.t_3 wrote: ... quoting radiance a substantial better voxeling performance is already on the list of upcoming improvements for beta 2.6 - what will result in a notable better loading time for large poly scenes. and as soon octanerender "native" plugins become available, the whole exporting/importing process will be cutted to 0. so the only thing for you to hope is, that a xsi plug is in the works...
face
„The obvious is that which is never seen until someone expresses it simply ‟
1x i7 2600K @5.0 (Asrock Z77), 16GB, 2x Asus GTX Titan 6GB @1200/3100/6200
2x i7 2600K @4.5 (P8Z68 -V P), 12GB, 1x EVGA GTX 580 3GB @0900/2200/4400
1x i7 2600K @5.0 (Asrock Z77), 16GB, 2x Asus GTX Titan 6GB @1200/3100/6200
2x i7 2600K @4.5 (P8Z68 -V P), 12GB, 1x EVGA GTX 580 3GB @0900/2200/4400