OctaneRender® 1.024 beta 2.49b RC (lin/mac/win) [OBSOLETE]

[funk]

Found a crash bug and a non-fatal bug with the new color picker

Crash bug:

1. Load the demo scene "hallyway.ocs" (although any scene will do)
2. select the material picker and pick the ceiling light
3. Press the color swatch to bring up the picker
4. Click on the hex value to highlight it
5. Right click and choose COPY. As soon as I select COPY the color picker hides, and octane crashes.
Note: This crash only seems to occur when the position of “copy” is NOT over the color picker (when it hovers past the bottom edge).
See attached image

Bug 2:

Color picker values dont match the diffuse value in the side panel. In my image the diffuse value is 0.9,0.9,0.9 but the color picker shows 0.953,0.953,0.953
It looks like one of the values might be gamma corrected?

[JimStar]

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).

My IMHO about this:
NO, NO and NO. This must not be done. RS team, don't do this! All is right done at the moment with this.
Otherwise, when needing to get an ready-made material, we will get the same dependence-resolving nightmare as in Unix-systems when getting an already compiled soft... With lot of time lost to manually resolve all these dependencies... And all universality of fast sharing .OCMs between people and fast and easy using it will be lost. And all that - to save a few bytes on disk, in the age of very cheap and fast storage... In Unixes this makes sense, as it saves RAM, but it makes no sense nowadays to spend all this additional work and time resolving dependencies - to save few bytes of cheap disk storage...
Just opinion of man exhausted by dependency resolving....

[matej]

@JimStar, what are you talking about? What dependency resolving?

I'm asking for two ways of saving a macro: with embedded textures and with a link to image file == flexibility. Nothing will be lost, because nobody will force you to use the second way. But I will gladly take advantage of it, because I don't want all my texture data duplicated each time I use them in a macro saved to .ocm. Also if your images are embeded in the .ocm, you cant edit them. If you edit the original, you must reload it everywhere it was embedded. Thanks, but no thanks

A few bytes? Try to save an .ocm with multiple 4096x4096 RGB textures referenced in it and tell me how much space does it take Also, try to load a few such macros (5 - 10) in your .ocs project and then see how much time it will take to save the .ocs (each embedded texture is re-saved each time you save the .ocs).

All they need to do is add the functionality to save a file path (which is how it's done in the .ocs) also to the .ocm files. That's hardly a lot of work and time resolving dependencies

[JimStar]

A few bytes? Try to save an .ocm with multiple 4096x4096 RGB textures referenced in it and tell me how much space does it take Also, try to load a few such macros (5 - 10) in your .ocs project and then see how much time it will take to save the .ocs (each embedded texture is re-saved each time you save the .ocs).

I don't care "how much space does it take". And yes, it is indeed a few bytes in terms of current time and cost of storage at this time. I have a RAID of few 2TB disks cached with SSDs Vertex-3 for speed - and do NOT think about these little things when need to save .OCMs and don't have problems with it. Just if needed - will buy a more disks...
Just my IMHO... In any case it will be decided by RS team, not by us, so let they hear all the opinions.

[JimStar]

Just tried command line switches: --output-png16, --output-exr... Not works...
It seems that in 2.49b is not yet implemented command line management of output formats... Or switches are some others...

[matej]

In any case it will be decided by RS team, not by us, so let they hear all the opinions.

How will an additional method of saving macro data, negatively influence your current work flow?

I guess that RS should not do any speed optimisations, either, cause we can always buy more GPUs

[JimStar]

I guess that RS should not do any speed optimisations, either, cause we can always buy more GPUs

Not correct analogy.

How will an additional method of saving macro data, negatively influence your current work flow?

I will be influenced by the lack of order as a consequence. It will be lot of untidy users who will share .OCMs with referenced textures instead of included. And .OCM-storages will be full of such junk. As it constantly going with .max models and scenes that users share with references to forgotten textures. I do not want such a disorder. This will influence me.

[matej]

Of course such thing won't happen, because the LiveDB will allow only macros with embedded textures

And whoever will share macros by different means, will have the responsibility to pack all the resources accordingly - like we do with every other stuff we share around. The idea of not having some useful functionality just because someone might forget to include textures is really funny.

[JimStar]

Of course such thing won't happen, because the LiveDB will allow only macros with embedded textures

I will share a secret: it is not only LiveDB in the net. There are a lot of sites where you can get e.g. .MAX models, and the more Octane will become popular - the more storages in Internet will have .OCS shared. And nobody of admins of these sites will check these uploaded .OCMs, as they do not check this .MAX junk with forgotten textures at the time. I work a lot with users (I'm ERP programmer, it is my wife 3D-proffessional), and have understood a long time ago: if you want to have an order - you can not let to users themself to follow the order, you must give a strong mechanisms that they must follow. In the other case - you will 100% become disorder.

[Isotemod]

Ive saved a ocs file with this version and when I reloaded octane was unable to find the mesh or texture files for the scene.

It then opens a dialogue to find them manually which it does so at the location specified in preferences.

Looking manually at my .ocs file there is difference between the new .ocs and previous .ocs files.

The path to the mesh and textures starts "<linkedfilename>..\..\Desktop" in the new .ocs but the old one has "<linkedfilename>..\Desktop"

I have relative paths ticked in the preferences.

UPDATE

I went through and found the mesh and textures for octane then saved it without relative paths ticked and reloaded fine.

On a different .ocs that I saved in this version with relative paths octane had no problem.

Resaving the the original file with relative paths enabled reproduced the same result on reloading.