nullptrnullptrnullptrnullptr123
Hi, this is one of those topics where it is not very trivial to give solutions by just looking into a code snippet. The hypothesis could be that Blender might expect mouse-move to happen before the click, to update some internal state of a button. Is just a wild guess, but maybe you need to generate mouse-move to the position of button-press.
There are a number of command line arguments, like --debug-events
which could provide some insights about what is going on.
Also, there was a GSoC back in 2012 related on the Android port, so maybe you can dig some useful things from there: archive/blender-archive: Archive of Blender with old branches - blender-archive - Blender Projects
you are running blender on android? thats interesting
Moderation notice: I merged two other threads into this one and made it generic, it’s much better to discuss all issues related to the Android port in one topic.
There is only that far we can give guidance based on description of a problem and its screenshots.
We don’t even know if the work is based on OpenGL, OpenGL ES, Vulkan, or something else.
If some graphics artifacts happen on a desktop, then is better to report them as a bug.
For the Blender port on Android, being able to see code and changes might make certain investigations easier.
Btw, are you planning on upstreaming the changes you’re working on?
It goes via the Grease Pencil render engine, found at source/blender/draw/engines/gpencil/gpencil_engine_c.cc
.
Not sure there is an overview of exact algorithms, but the GPENCIL_draw_scene()
would be a good starting point to see what is is going on.
Also, keep in mind, quite some stuff has changed with GPv3, so it might be good idea to check the latest main
branch.
OK ! Thanks a lot. I will step into the function.
Hello everyone! I have encountered several problems during the porting process recently. If you encounter similar problems during the development process, please feel free to give me some advice and provide some clues or ideas. Thank you.
Question 1:
After adding a texture to the model, the model is displayed as a solid color in the material preview mode and display rendering mode, and no matter what texture is added, it displays the same solid color.
However, in texture drawing mode and solid display mode, the map can be displayed normally.
In addition, adding a background image to the scene will also display normally regardless of the rendering mode.
Question 2:
Add a spline curve to the scene. The added spline curve has an additional straight line and a point at the end of the straight line.
Question 3:
After adding the translation module and switching to Chinese, some opened pages can be displayed normally, but some Chinese characters on menus and toolbars that need to be expanded are not fully displayed. What can be confirmed is that the translation content in the translation file can be correctly obtained through msgID. After restarting, some can be displayed completely, but some still cannot be displayed completely.
There appears to be more going on than just a change to the Chinese language. Some English portions are displaying with very odd spacing. From your sample, see “View Layer” and “Collection” looking much wider than we see them normally. Is the font changed from the one we distribute (Inter) ?
The text is probably being culled, and the root problem is probably the same as why english text is rendered differently.
The missing texture might be just a missing feature in OpenGL ES. Maybe stepping through IMB_create_gpu_texture
could give some clues.
Oh. I changed the font and changed the original font to HarmonyOS font to support Chinese fonts.
before fixing
/* File name of the default variable-width font. */
#define BLF_DEFAULT_PROPORTIONAL_FONT "DejaVuSans.woff2"
/* File name of the default fixed-pitch font. */
#define BLF_DEFAULT_MONOSPACED_FONT "DejaVuSansMono.woff2"
After
/* File name of the default variable-width font. */
#define BLF_DEFAULT_PROPORTIONAL_FONT "HarmonyOS_Sans_SC_Regular.ttf"
/* File name of the default fixed-pitch font. */
#define BLF_DEFAULT_MONOSPACED_FONT "HarmonyOS_Sans_SC_Regular.ttf"
Regarding rendering, because OpenGL 3.1 ES uses medium float precision, does not have sampler1D, sampler1DArray, and the glsl program does not support the ##splicing macro, the most modified areas are the various glsl shader programs.
I observed the rendering results above and personally feel that there is a problem with the lighting-related calculations of Eevee. The glsl programs that I modified the most are closure_eval_surface_lib.glsl and effect_reflection_resolve_frag.glsl, which expanded the original function containing the ##splicing macro.
Such usually require checking for something obvious like errors in the console (possibly with --debug-gpu
), or attaching to the actual process with RenderDoc to see what happens at which render pipeline stage.
It is not something that can be easily troubleshooted over an offline forum conversation.
Hello everyone, please ask. During the process of debugging the blender4.0.0 code, I found that the created GPU_TEXTURE_CUBE did not specify data, but was used in the shader program. Not sure which process I’m missing.
First Cube:
Second Cube:
Yes.
I am slowly debugging the blender code and printing a lot of logs.
However, debugging on Android is not as convenient as debugging on the desktop platform.
I have also tried to use renderdoc to troubleshoot, but I am not familiar with renderdoc at the moment, so I can only simply look at the output of each frame.
If eevee and Greece pencil works on Android it will be a massive win . I really appreciate your efforts for this .
The texture is used as an attachment to a frame buffer, so it is expected that data is not provided when the texture is created.
Also please note that the code has changed quite a bit in 4.2 with the Eevee-Next project landed.
can you please share the git repo of this? I would like to try it
Have you considered just porting the sculpting and modeling sections of blender to android and leaving the rest for the desktop version as I can imagine people using them to create models on a tablet and importing to the desktop version for animation composition and rendering
There are still some basic things that are not handled well.
There are many dependencies and changes in the process of porting. If I were to create a repository on GitHub, I would have to sort it out.