I have compiled from Cycles render lastest(up to January 27) as standanlone (Visual Studio Community 2017) and successfuly creating but once to launch in rendering is fully black so it was because of problem to OCIO environment variable but I have fixed it… Still black
Have you thinking what it is the problem ? Or is it from OCIO issue? If it is OCIO I make the path for aces version 1.03, it is good or not ?
Hope you can help me because I have not idea on what it causes this black rendering.
AFAIK right now Cycles standalone misses the UI part, that has to be updated, it seems that you can however save the resulting render to an image file, don’t ask me how because I don’t use Cycles Standalone, but it seems you can.
Cycles standalone has a small UI for just rendering but not option like saving image on screen or I may be not to know on how to save it ?.. I think the problem is from OCIO stuff render to incorrect result. Before that the old code (in 2021) working great without problem and without making path for OCIO… So I don’t know how to fix that from lastest version.
That small UI is what is missing, so Cycles has no way to write their pixels to anything you can view, you can output the resulting image to a file, but as I said I don’t know how to do it since I don’t use standalone for anything, @brecht would know this better
Ok after research it, I update to up for Fev 14 with Cycles dev now, working too this lastest version, I make OCIO path from Blender and do it in command line as cycles --samples 100 --output image.png scene_cube_surface.xml so it is working very well I have image rendering with all colors
Only in directly rendering (about in visual on screen) is still black, Hope @brecht with his team can fix that in later version.
SDL is very good too but as it says it is not part from libraries so I suggest you a gui more easy without dependencies and open source so it is very small codebase compared to SDL, his name is Nuklear (inspired from imgui), see it from features, his source code is C and compatible with C++.
Whille that could bring back some on screen UI, it won’t help with the SDL dependency, Nuklear is a higher level library, it still needs a backend like SDL/GLFW/SFML for opengl support.
Not necessarily to those backend SDL/GLFW/SFML, they are just as demo example, you can extend without SDL and do it with backend GDI+OpenGL by example, it needs just on how to make right it. It is cross platform so it can make X11 + OpenGL as well… I am sure it is possible to make MacOS + OpenGL or Metal but it has no demo but feasible. As I am not in a position to help you because I discovered Nuklear recently so they have to contact dumblob (the link I gave you) more info and if brecht and his team agree to assist for this development.
It’s a suggestion, not a need absoutely. If SDL works for them I am ok too
Nuklear’s GDI(P) examples are pure GDI, no OpenGL , sure you could add the code to make an OpenGL context but we used SDL since it provides a nice uniform way to get an OpenGL context across platforms, having to write/maintain backends our selves somewhat defaults that purpose.
Ok I have compiled recently this lastest Cycles from github and SDL, it works with all colors on screen very well so I say you @brecht and his team again great work and thanks your big support ! You are all genius !
Now I can work for Cycles render standalone in way more calm et learn more it ^^.
