OctaneRender® 1.024 beta 2.48b TEST (lin/win) [OBSOLETE]

A forum where development builds are posted for testing by the community.
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.
Post Reply
User avatar
abstrax
OctaneRender Team
Posts: 5509
Joined: Tue May 18, 2010 11:01 am
Location: Auckland, New Zealand

kubo wrote:small bug, I just reseted a locked render cause I had the focus pick selected prior to locking it and when I wanted to scroll, ctrl+lmb I accidentally refocused the scene and started back from zero.
Thanks for that. Will be fixed in the next release.

Marcus
In theory there is no difference between theory and practice. In practice there is. - Yogi Berra
User avatar
pixelrush
Licensed Customer
Posts: 1618
Joined: Mon Jan 11, 2010 7:11 pm
Location: Nelson, New Zealand

once you drag in a material from the LiveDB clicking on the material in the outliner project .obj inputs doesnt bring up the whole material in the node inspector, as it does for 'in house' mats, works for the subgraphs though.
changing material types in the node insp collapses the inputs tree in the outliner - which is unhelpful...

once you drag and drop a mat from the outliner LiveDB view onto the render window it can take a more than a few seconds to appear/download. might need a wait cursor for user feedback.

actually same need for user feedback applies when changing resolution particularly for big res...(actually can be about 1min here - see below - too long really..needs to be improved if it can be ;) ) and also pan and zoom in big res. ideally of course you set up everything in a small res and then change up to render the final, never the less...

512sq -> 8192sq = 25s
8192sq -> 512sp = 30s
8000sq -> 8192sq = 59s
8192sq -> 8000sq = 68s

in 2.47 times were better - call it a 'bug' then ;) the times do vary a little if repeated.
for 2.47 with as above resolution changes:
17s
9s
27s
20s

the good news is that there was a bug changing to 8192sq in 2.47 where the image was all white that is not there in 2.48
...and the re-centering now works where the image has been zoomed without it resetting to full size :) ...although I just did something now where the view is now all white no matter what resolution...hmmm... what was that I did...something to do with recenter and reset to original view... :? :roll:

agh! enough for today.. :geek:
Last edited by pixelrush on Fri Jul 15, 2011 2:18 am, edited 4 times in total.
i7-3820 @4.3Ghz | 24gb | Win7pro-64
GTS 250 display + 2 x GTX 780 cuda| driver 331.65
Octane v1.55
mirobimbo
Licensed Customer
Posts: 108
Joined: Tue Dec 21, 2010 10:43 pm
Location: Slovakia

OctaneFX wrote:I noticed a new feature in this release :
we can now switch between multiple cameras while rendering, with immediate change in the render viewport.
Thanks for this appreciated functionality!
How did you join multiple cameras with one node please, i can join only one camera with one node.
Sorry my English.
User avatar
Elvissuperstar007
Licensed Customer
Posts: 2508
Joined: Thu May 20, 2010 8:20 am
Location: Ukraine/Russia
Contact:

1) The new engine slows down, your settings, ISO, exposure, etc.
2) when the sun turned the scene does not react to it! only after a certain time is spent on 40 seconds of deliberation

sorry for bad english
win 7 /64x C2Quad 6600 2.4/ Nvidia 9800 GX2 1gb 512 bit + Asus 480 GTX/ DDR2 8Gb / NVIDIA 460 GTX 2GB/2x NVIDIA 580 GTX 3GB
Page octane render " В Контакте " http://vkontakte.ru/club17913093
User avatar
Jaberwocky
Licensed Customer
Posts: 976
Joined: Tue Sep 07, 2010 3:03 pm

abstrax wrote:
Jaberwocky wrote:Another query.This time more of a logical one than a bug.
In a real camera analogy a depth of field is created by the lens aperture.
F1.4 is very fast letting in lots of light but with a very shallow depth of field.
when you get down to around F22 you have almost infinite depth of field but requiring a longer exposure to get lots of light to get an image.

Surely these two controls I have highlighted in the attachment should really be set as one slider only, if the Camera lens analogy is going to work.This slider should really be labelled as a series of F stops from say F1.2 to F22.

You already have the autofocus point eye dropper tool on the tool bar to focus the lens on the relevant point in the scene , as an autofocus lens would in real life.Couple that with the aperture slider described above. That should duplicate a Camera lens correctly.The remainder of the camera controls you already have.The ISO Slider should be re label'd to ISO settings 64 / 100 / 200/ 400 / 800 / 1600 / 3200 / 6400 as they are currently on most Digital SLR's.The scene image would get progressively grainier as the slider approach's the higher ISO values. This way anyone who uses octane and who also does photography should instantly be able to replicate a photographic situation.

The current interface sort of smacks of over complication.

Any other views on this suggestion ?
Regarding aperture and focalDepth: focalDepth is not the width of the range in focus, but the distance/depth of the plane in focus from the camera.

Regarding UI: Well the UI/nodes have grown over time and there 2 seperate things that you want to mix together: The render camera and the tone mapping. The render camera controls the DOF and tone mapping the exposure. Internally they are not related, since the renderer doesn't really work like a camera.

We will probably streamline the UI in the future, but we have to figure out a way that doesn't break old files. The biggest problem I see here is that the aperture is given as diameter and not as f/stop as it's done in photography. We'll see...

Cheers,
Marcus
Ok . Thanks for the Info.

Regarding my other comment.In 2.46b if i opened the render preview window to full screen, I then had to Ctrl zoom to get the image in it to fill the screen.in 2.48B when i open the render preview to full screen .The image in it will automatically fill the enlarged screen.Not sure if this is a cured bug or just an improvement you made.Anyway it works fine.Thanks.
CPU:-AMD 1055T 6 core, Motherboard:-Gigabyte 990FXA-UD3 AM3+, Gigabyte GTX 460-1GB, RAM:-8GB Kingston hyper X Genesis DDR3 1600Mhz D/Ch, Hard Disk:-500GB samsung F3 , OS:-Win7 64bit
vipvip
Licensed Customer
Posts: 726
Joined: Fri Apr 22, 2011 9:28 am

Animation of objects now working with 2.48b ! :)
Congrats and many thanks for alpha shadows with direct lightning !! :D
Cheers
User avatar
pixelrush
Licensed Customer
Posts: 1618
Joined: Mon Jan 11, 2010 7:11 pm
Location: Nelson, New Zealand

ok retest and further info..
for directlight and pathtracing res change time is *reasonable* (below). DL is a little faster. PMC is the trouble. had some crashes too. will try to corner it.. :ugeek:
A progress bar for res over 4000 for DL and PT might be good, and under that use a wait cursor.
for PMC changes, if it is always to be like this, could be set to show the prog bar at 2000.

512 -> 8192 7s, 11s
8192 -> 512 8s, 13s,
8000 -> 8192 9s, 14s
8192 -> 8000 7s, 21s

there must be a better way to handle PMC? waiting about a minute for the update seems like a lot of processing time going by? a bit disconcerting for the user too. ;)
looks like it hung or that the change wasnt done so the natural tendancy is to repeat it or try something else like pan in the viewport - probably leading to a crash from queued events... :roll:

even exiting Octane from a PMC render is slow. probably not helped by the 5 sec refresh times either.

ok enough chasing - I'll leave it to the happy coders to 'fix' :) as it is though its not so hot. :(
it also needs to be said a GTX460 is a reasonable card so the situation with lesser hardware is going to be even less desirable.
Last edited by pixelrush on Fri Jul 15, 2011 2:19 am, edited 2 times in total.
i7-3820 @4.3Ghz | 24gb | Win7pro-64
GTS 250 display + 2 x GTX 780 cuda| driver 331.65
Octane v1.55
User avatar
Refracty
Licensed Customer
Posts: 1599
Joined: Wed Dec 01, 2010 6:42 pm
Location: 3D-Visualisierung Köln
Contact:

Hi Jaberwocky,

I agree with you that the settings in the 'camera' and 'mesh preview imager' need to be more 'linked'.
But I don't see any logical reason to link the apperture with focal depth. These are indipendent values that need no linking in photography.
What definately needs a linking is the apperture, shutter speed and exposure value. So when you change one value, at least one other value (of the other two) has to change accordingly. The exposure value is a logarithmic product of the shutter speed and apperture/fstop so this is linked anyway. You might ask where is the shutter speed, and it seems that this important thing does not exist in octane! On the other side the apperture exists twice, because apperture (Mesh Preview Imager) and fstop (camera) is the same! That is indeed very strange.
Also some of the values are wrong like you have addressed correctly. The apperture / fstop should start with below 1 (not 1.2 in my view) because you can get a very expensive Leica lenses which start with an fstop below one. I wouldn't constrain the iso to specific value steps. But I would at least allowing an iso of 6400 or higher (25.000).
I would not like to have more graininess with a high iso. A good camera shows little visible grain in high iso (like Nikon 3Ds). So this is something for the post. But a grain slider could be a nice feature like we have vignetting. (Also vignetting is linked with the apperture / fstop in reality but I would not go so far and keep it flexible.)
But there is one important linking and I think this is what you have meant. The linking of the depth of field effect with the apperture/f stop. Yes that is definately important. They have already named it apperture but the fstop attribute in the "mesh preview imager node" makes no sense then.
This is CG so I really think that a software can be way more flexible in terms of what values can be put in but some relations of values should be represented in the behaviour.
Another important thing what I have said in an earlier post is that I don't think it is a good idea to put the iso, fstop, exposure into a node outside the camera. These are camera specific values and should stay in the camera node. Especially when you deal with multiple cams with different values it makes work easier.

Any other suggestion appreciated.
Cheers
Refracty

Jaberwocky wrote:Another query.This time more of a logical one than a bug.
In a real camera analogy a depth of field is created by the lens aperture.
F1.4 is very fast letting in lots of light but with a very shallow depth of field.
when you get down to around F22 you have almost infinite depth of field but requiring a longer exposure to get lots of light to get an image.

Surely these two controls I have highlighted in the attachment should really be set as one slider only, if the Camera lens analogy is going to work.This slider should really be labelled as a series of F stops from say F1.2 to F22.

You already have the autofocus point eye dropper tool on the tool bar to focus the lens on the relevant point in the scene , as an autofocus lens would in real life.Couple that with the aperture slider described above. That should duplicate a Camera lens correctly.The remainder of the camera controls you already have.The ISO Slider should be re label'd to ISO settings 64 / 100 / 200/ 400 / 800 / 1600 / 3200 / 6400 as they are currently on most Digital SLR's.The scene image would get progressively grainier as the slider approach's the higher ISO values. This way anyone who uses octane and who also does photography should instantly be able to replicate a photographic situation.

The current interface sort of smacks of over complication.

Any other views on this suggestion ?
livuxman
Licensed Customer
Posts: 118
Joined: Thu Jan 28, 2010 5:58 pm
Location: Valencia

I'm testing the new version (in linux) and I can't find the portal material . Where should appear?

About the new multi-GPU engine, I have to say is the first time I can use my GTX260 in conjunction with the GTX470 and winning in performance. Good job.
LiVux 64bit | Geforce GTX260 Core 216 and GTX470 | i7 860 | 8Gb | Drivers 275.09.07 | Cuda 4.0.17
User avatar
abstrax
OctaneRender Team
Posts: 5509
Joined: Tue May 18, 2010 11:01 am
Location: Auckland, New Zealand

livuxman wrote:I'm testing the new version (in linux) and I can't find the portal material . Where should appear?

About the new multi-GPU engine, I have to say is the first time I can use my GTX260 in conjunction with the GTX470 and winning in performance. Good job.
If it's not in materials (where you can also find diffuse material), then we probably forgot to include a file. Sorry about that. It will be fixed in the next release.

Thanks for the heads up anyway.

Marcus
In theory there is no difference between theory and practice. In practice there is. - Yogi Berra
Post Reply

Return to “Development Build Releases”