This release is very nice stable and fast thx octane team
i render my old DNS5000 and is fast
OctaneRender® 1.024 beta 2.49b RC (lin/mac/win) [OBSOLETE]
Forum rules
NOTE: The software in this forum is not %100 reliable, they are development builds and are meant for testing by experienced octane users. If you are a new octane user, we recommend to use the current stable release from the 'Commercial Product News & Releases' forum.
NOTE: The software in this forum is not %100 reliable, they are development builds and are meant for testing by experienced octane users. If you are a new octane user, we recommend to use the current stable release from the 'Commercial Product News & Releases' forum.
- EricDesign
- Posts: 353
- Joined: Thu Mar 25, 2010 8:19 pm
- Location: canada
- Contact:
wooo sorry I am a little late to the party.
Seems like a really good release guys will keep looking but its probably only small stuff.
Appears to be a bit snappier too.
The issue I had with the view port going white while panning,rotating for subsampling is fixed.
CPU use is well down - almost zero where before it was 50%
Small request:I wonder if you could make the samples, time etc text just a little bigger now?
To my old eyes it tends to run together a bit. Other users may feel differently though
BTW I want to compliment the Refractive team on the way you have applied yourselves lately.
I think you are making sound progress now and have a good balance of forum participation and coding. Excellent work - keep it up. The new features arriving with each test are welcome too
edit:
bug when adjusting colour picker value- see attach pic.
RGB value in picker is not consistent with the inspector one except at 0 or 1.
had a few crashes so far unrelated to this issue - not sure why - might have been induced cos I left it rendering for a while and then tried to make a change...
Seems like a really good release guys will keep looking but its probably only small stuff.
Appears to be a bit snappier too.
The issue I had with the view port going white while panning,rotating for subsampling is fixed.
CPU use is well down - almost zero where before it was 50%
Small request:I wonder if you could make the samples, time etc text just a little bigger now?
To my old eyes it tends to run together a bit. Other users may feel differently though

BTW I want to compliment the Refractive team on the way you have applied yourselves lately.
I think you are making sound progress now and have a good balance of forum participation and coding. Excellent work - keep it up. The new features arriving with each test are welcome too

edit:
bug when adjusting colour picker value- see attach pic.
RGB value in picker is not consistent with the inspector one except at 0 or 1.
had a few crashes so far unrelated to this issue - not sure why - might have been induced cos I left it rendering for a while and then tried to make a change...
i7-3820 @4.3Ghz | 24gb | Win7pro-64
GTS 250 display + 2 x GTX 780 cuda| driver 331.65
Octane v1.55
GTS 250 display + 2 x GTX 780 cuda| driver 331.65
Octane v1.55
ok more issues..
saving a turntable or daylight animation should probably allow same image formats as elsewhere - .exr and .png 8/16
my trial of both types of animation rendered the sequences without any camera rotation or sun movement respectively - ie all images are the same although correctly numbered.
no rendering or rotation was happening in the viewport either
HTH
edit: tracked it down
the above issue with not rendering an animation correctly occurs only with 4x4 subsampling selected
edit: another small request
a 640x360 resolution preset for YouTube would be appreciated 
edit: small bug - in anim panel the tool tip for Direction left/right = Frames per second
saving a turntable or daylight animation should probably allow same image formats as elsewhere - .exr and .png 8/16
my trial of both types of animation rendered the sequences without any camera rotation or sun movement respectively - ie all images are the same although correctly numbered.
no rendering or rotation was happening in the viewport either
HTH
edit: tracked it down

edit: another small request


edit: small bug - in anim panel the tool tip for Direction left/right = Frames per second
Last edited by pixelrush on Sun Aug 14, 2011 9:58 pm, edited 8 times in total.
i7-3820 @4.3Ghz | 24gb | Win7pro-64
GTS 250 display + 2 x GTX 780 cuda| driver 331.65
Octane v1.55
GTS 250 display + 2 x GTX 780 cuda| driver 331.65
Octane v1.55
- EricDesign
- Posts: 353
- Joined: Thu Mar 25, 2010 8:19 pm
- Location: canada
- Contact:
OCTANE v1 2.49 Rc dn-h1000s
just another test for octane 12min render 3000sample with 470GTX
just another test for octane 12min render 3000sample with 470GTX
- enricocerica
- Posts: 1012
- Joined: Wed Nov 25, 2009 7:32 pm
- Contact:
Hi,
Made some quick tests.
Octane crashes when loading a 378 Mb mesh object, if works fine with 2.49.
Did you changed something in the memory allocation ?
Made some quick tests.
Octane crashes when loading a 378 Mb mesh object, if works fine with 2.49.
Did you changed something in the memory allocation ?
Modeling system : I7 32GB Windows 10 & Fujitsu Celsius H720
GPU : 1x Gigabyte GTX580 3GB + 1x MSI GTX780 3GB + 1x PALIT GTX780 6GB +1x Asus Stix GTX1070 8GB
http://www.myline.be
GPU : 1x Gigabyte GTX580 3GB + 1x MSI GTX780 3GB + 1x PALIT GTX780 6GB +1x Asus Stix GTX1070 8GB
http://www.myline.be
Awesome stuff guys! Testing it now.
Noticed a small tooltip bug. If I mouse over the 2x2 subsampling icon then slide over to the 4x4, the tooltip still says 2x2. The same happens in reverse. I have to mouse over another icon before the subsampling ones to see the correct tooltip text.
Edit: I just noticed my browser doesnt feel as sluggish now when rendering with PT. Good stuff!
Noticed a small tooltip bug. If I mouse over the 2x2 subsampling icon then slide over to the 4x4, the tooltip still says 2x2. The same happens in reverse. I have to mouse over another icon before the subsampling ones to see the correct tooltip text.
Edit: I just noticed my browser doesnt feel as sluggish now when rendering with PT. Good stuff!
Win10 Pro / Ryzen 5950X / 128GB / RTX 4090 / MODO
"I am the resurrection, and the life: he that believeth in me, though he were dead, yet shall he live" - Jesus Christ
"I am the resurrection, and the life: he that believeth in me, though he were dead, yet shall he live" - Jesus Christ
Thumbs up, dev team! 
This new version is completely different from the last 249. Now the GUI is back again responsive as Octane eats only one of my CPUs when rendering. The new color picker is awesome!
warning: feature request follows...
One small thing that I'm really annoyed the whole time; why still can't we save an .ocm with just a path to textures, instead of all the textures embedded into the file? Now the closest thing to duplicating / reusing your materials is to save the macro into an .ocm, open it and then manually re-link all the textures inside to point to the files and not to the embedded data. If you don't do this, your .ocs will get progressively fatter and slower to save, as you import additional macros... I would like to have a "local material db" functionality without it eating gigs of duplicated texture data, because images are saved in the .ocs (and uncompressed on top of that).
Another small useful thing is to make so that the program writes down both the relative and absolute path for a resource file. If the loader can't find a resource on one path, try the other. This way the project can be moved without breaking everything (= more robustness).
This are such small tweaks to do and would really help in the whole experience.

This new version is completely different from the last 249. Now the GUI is back again responsive as Octane eats only one of my CPUs when rendering. The new color picker is awesome!
warning: feature request follows...

One small thing that I'm really annoyed the whole time; why still can't we save an .ocm with just a path to textures, instead of all the textures embedded into the file? Now the closest thing to duplicating / reusing your materials is to save the macro into an .ocm, open it and then manually re-link all the textures inside to point to the files and not to the embedded data. If you don't do this, your .ocs will get progressively fatter and slower to save, as you import additional macros... I would like to have a "local material db" functionality without it eating gigs of duplicated texture data, because images are saved in the .ocs (and uncompressed on top of that).
Another small useful thing is to make so that the program writes down both the relative and absolute path for a resource file. If the loader can't find a resource on one path, try the other. This way the project can be moved without breaking everything (= more robustness).
This are such small tweaks to do and would really help in the whole experience.
SW: Octane 3.05 | Linux Mint 18.1 64bit | Blender 2.78 HW: EVGA GTX 1070 | i5 2500K | 16GB RAM Drivers: 375.26
cgmo.net
cgmo.net
Nice one DevTeam!
I'll start chasing bugs on monday!
@Matej: Instead of having a LocalDB (That I also think is necessary) you could upload all your materials to the LiveDB and browse them there for every need you have! As I know you are such a good material creator that would help the LiveDB to grow with your nice materials too!
Cheers
I'll start chasing bugs on monday!
@Matej: Instead of having a LocalDB (That I also think is necessary) you could upload all your materials to the LiveDB and browse them there for every need you have! As I know you are such a good material creator that would help the LiveDB to grow with your nice materials too!

Cheers
Rampage IV Extreme+i7 3920k+2x GTX580 3GB+2x GTX470
Being forced to upload materials to LiveDB, just to be able to easier work with them, is not a solution. Materials can't be uploaded for various reasons; too big textures, license reasons, project specific / model specific textures, etc.. A "local DB" is a necessity that many have asked for.
And I'm not even asking for a fully featured "local db". Just to be able to easier manage my material resources, without such annoyances I described previously.
And I plan to share my materials on the LiveDB - when the additional node functionality will be implemented, that the shading system (and LiveDB service) badly needs to be really usable.
And I'm not even asking for a fully featured "local db". Just to be able to easier manage my material resources, without such annoyances I described previously.
And I plan to share my materials on the LiveDB - when the additional node functionality will be implemented, that the shading system (and LiveDB service) badly needs to be really usable.
SW: Octane 3.05 | Linux Mint 18.1 64bit | Blender 2.78 HW: EVGA GTX 1070 | i5 2500K | 16GB RAM Drivers: 375.26
cgmo.net
cgmo.net