[BUG]laggy and freezes

[NoPlan123]

I'm using a GeForce RTX3080 and had a mysterious big lag when moving the viewport and editing polygons with this add-in. I solved it by setting all actions with blender.exe to default settings in the GeForce driver control panel. If you encounter the same phenomenon, try that setting.

However, it still gives the impression of being very unstable. Just popping up the options menu will significantly reduce the frame rate. The PolyPen has difficulty with accurate vertex selection, runs amok and freezes Blender for a few seconds.

In the case of the repository, it is recommended to use the same graphics engine as Blender because it is not necessary to stick to the display function.

Blender3.6 RetopoFlow3.4 Windows11 pro Threadripper 2950X 64GBRam GeForce RTX3080

[vxlcoder]

thanks for the details!

what are the vert/tri/poly counts of your meshes?

also, can you record a video of it acting up?

[NoPlan123]

A high poly is about 640k polygons. https://drive.google.com/file/d/1gyNSW-H0WMBKLCiuBZEww3jEfjqKk_1s/view?usp=sharing

And when I use symmetry, the cursor goes to the opposite side.

[vxlcoder]

thanks for the screen capture! this is very helpful.

here are a few notes on what I've observed...

First, in RF v3.4, I had to remove some optimizations on the UI rendering to switch from the deprecated bgl Blender module to the new gpu module. I'm hoping to get that optimization turned back on as soon as possible, but I think there might be either a bug in gpu module or I'm using it incorrectly. (still tracking it down). as a workaround, try pressing F9 to turn off/on the main windows (menu, options, geometry) or collapse the options menu when you don't need it. I know it's not convenient, but this is an issue that I'm actively working on, but we wanted to get v3.4 out as quickly as possible.

RetopoFlow is designed to have target geometry on the +X side of the mesh, but your target geometry is on the -X side. Blender does not care too much which side you work on, as long as you're consistent, but RF does. With symmetry enabled when you start RF, RF should report a warning that Symmetry is enabled, but vertices were found on the "wrong" side of the symmetry plane. A quick fix is to switch to edit mode on the target, select all, hit S to scale, hit X to scale along X-axis, type -1 to mirror verts along X-axis, and then Enter to confirm. This is an area that we're working on.

A new (and still very early) feature to RF v3.4 is mirroring the actions across planes of symmetry. When you enabled symmetry and then tried doing actions on the -X side (ex: Relax), the visualization showed on opposite side. Again, this is due to RF preferring the geometry to be on +X side of the target.

with PolyPen, I haven't noticed it having difficulties in selecting the correct geometry, but I'll look a bit more into that. the delay that you see when using PolyPen might be related to the UI drawing performance issue that I noted above. Will take a look at it too.

in the end, you've found a few things that we're actively working on fixing.

On your original post, you mentioned about changing settings for Blender for the GeForce driver. can you provide a few more details on that? also, what do you mean by In the case of the repository, it is recommended to use the same graphics engine as Blender because it is not necessary to stick to the display function.?

thanks!

[imh1kiko]

Kinda chiming in, since similar issue. Due to this I've been almost completely avoiding Retopoflow (as this isn't tied down to this specific version).

I tried doing a clean install (download the latest stable build + factory reset on Blender, in case it's some other addons/settings interfering). The issue persists. It's almost as if it hates the hardware itself with a passion. This has been a problem since the beginning of 3.0 builds.

A showcase with random relatively low-poly object, and still lagging (debug section reported ~5fps. It only rises a few fps when UI minimized). https://drive.google.com/file/d/1gezC3tuQFe9NRyWyAgZ-EvFG2fAUrXKQ/view?usp=sharing

Specs: Sys: Win 10 21H2 (build: 19044.2965) CPU: i7 9750H GPU: GTX 1650 (mobile) (driver ver: 511.23) RAM: 16GB

[vxlcoder]

thanks for the additional details, @imh1kiko.

I was able to fix the UI performance issue I noted in my previous reply. We are hoping to get v3.4.1 out soon, but I will post a temp link to download a zip of the alpha version later tonight.

This has been a problem since the beginning of 3.0 builds

By "3.0 builds", do you mean RetopoFlow 3.0 builds or Blender 3.0 builds?

[imh1kiko]

Retopoflow builds. Sorry for that missing detail. But I do wonder if something outside (windows-specific) is causing these issues. A while ago there was case with Cura's UI and Windows Powertools (which I no longer have). Might be a leap of judgement though.

[vxlcoder]

@NoPlan123 and @imh1kiko, here is a temp link to RF v3.4.1 alpha. Please let us know if this improves your experience, even if slightly. thanks for helping me continue to work on this!

https://www.dropbox.com/s/ycdml8zlwvxyqca/RetopoFlow_v3.4.1-alpha-GitHub.zip?dl=0

[imh1kiko]

Would say the improvements are pretty noticeable. Debug info now reports higher fps. Seems to handle over 150k polys now with no problem. It's not too evident from the screen recording, but I can personally vouch for it running better.

There's an issue during a clean install however (sadly didn't take a screenshot of it), but works when files are overwritten with 3.4.0's build.

https://drive.google.com/file/d/1ZDKKkm45SoPI5fr0bt-YNAQ7_oGv8tvI/view?usp=sharing

[vxlcoder]

thanks for the details!

will look into the clean install issue you mention. do you recall what problem(s) you had then?

I am happy to hear it is working better. looks like startup is still much slower than I would like. will continue to improve this.

[imh1kiko]

Take it with a grain of salt (as I'm running this through sandboxie), but managed to recreate the error. The error gets thrown when user tries to install Retopoflow into a custom script directory, rather than into AppLocal (as that went fine).

Seems quite evident, since it looks from appdata, rather than where it's installed.

[vxlcoder]

oh, interesting...

that actually looks like a Blender bug

[Dangry98]

@NoPlan123 and @imh1kiko, here is a temp link to RF v3.4.1 alpha. Please let us know if this improves your experience, even if slightly. thanks for helping me continue to work on this!

https://www.dropbox.com/s/ycdml8zlwvxyqca/RetopoFlow_v3.4.1-alpha-GitHub.zip?dl=0

Wow! I have been experiencing beyond unusable performance ever since RetopFlow 3.3.0. I've been averaging around 5 fps for just 50 triangles in the Poly Pen tool, and experiencing constant freezes for sometimes even minutes after adding triangles with the pen tool. I repeat, this is with 50 triangles. This version of the addon is finally kind of usable and works much better, even with a few hundred or even a thousand triangles! I hope this is released soon, and that the performance will soon be back to the 3.2.9 level, where it can handle tens of thousands of triangles without any problems.

Specs: Ryzen 2700X, 48GB RAM, RTX 3060 12GB. The performance problems have been just as bad on other powerful or even more powerful computers.

[ozzycodes]

Sorry to add to this, but I have exactly the same issue. It's laggy and from some views it can't seem to select the right vertex, edge or face. My temporary solution is to rotate my view 90 degrees. As you can see, when working in front of the object, parallel to the Y axis, it does what is supposed to do, when working from the x axis, that's when the problems start.

MacBook Pro M2 Max, 96GB, Ventura 13.5

[vxlcoder]

@ozzycodes, sorry for the issues you're having. are you using RF v3.4.0 or v3.4.1 alpha? I believe this issue has been fixed. you may use this temp link to download the latest updates: https://www.dropbox.com/s/ycdml8zlwvxyqca/RetopoFlow_v3.4.1-alpha-GitHub.zip?dl=0

[dmitsuki]

Personally, I just tried 3.6 blender and 3.4.1 alpha retopoflow and placing 4 vertices with the polypen led to lag and horrible performance. Just went to 3.3 lts and 3.3 and so far the performance is far better. I'm willing to do any testing and give any debug info if this is not expected behavior, if you just let me know what you would require of me.

[vxlcoder]

thanks for the info, @dmitsuki. this seems unusual, though. could you provide a few more details on your situation?

• how big is the source mesh?
• what are your system specs?
• do you have any other add-ons enabled?
• does it run slowly if you load factory settings and enable only RF?
• is performance bad with other tools, too?
• can you capture a video of you using RF?

there seems to be something different with your particular setup that I haven't seen yet.

RF 3.3 and before used the bgl module for rendering, but bgl is deprecated (Blender 4.0 will not include it). so we had to switch to Blender's new GPU module, which is different but I believe RF 3.4 render code performance should be on par with 3.3. this is the biggest difference between 3.3 and 3.4. I also reworked some internal code, but those changes should only do less work in 3.4 than 3.3.

[dmitsuki]

thanks for the info, @dmitsuki. this seems unusual, though. could you provide a few more details on your situation?

* how big is the source mesh?

* what are your system specs?

* do you have any other add-ons enabled?

* does it run slowly if you load factory settings and enable only RF?

* is performance bad with other tools, too?

* can you capture a video of you using RF?

there seems to be something different with your particular setup that I haven't seen yet.

RF 3.3 and before used the bgl module for rendering, but bgl is deprecated (Blender 4.0 will not include it). so we had to switch to Blender's new GPU module, which is different but I believe RF 3.4 render code performance should be on par with 3.3. this is the biggest difference between 3.3 and 3.4. I also reworked some internal code, but those changes should only do less work in 3.4 than 3.3.

It's odd, I am not able to reproduce after clean rooming it, so I'm going to go ahead and retract that statement. Symmetry however is broken in 3.4.1a. If you change the merge distance, and cross the boundary, retopoflow errors out.

[vxlcoder]

great!

I did find and fix that symmetry bug.

will get a new zip made soon.

[vxlcoder]

use this temp link to download v3.4.1 alpha as of today: https://www.dropbox.com/s/ycdml8zlwvxyqca/RetopoFlow_v3.4.1-alpha-GitHub.zip?dl=0

[Shaggy90]

Hi. I work on a qutie good PC: i9-12900k RTX 3090 48GB RAM Windows 11

I tried Blender 3.4, 3.5, 3.6 with Retopoflow 3.29, 3.3, 3.5, 3.4.1 alpha The alpha build seems to be working best - at least panning and rotating viewport doesn't lag. But it's still really bad. Here's a video showing how edit mode works and Retopoflow in comparison. https://youtu.be/247EkcIChKc

As you can see, the source is one decimated mesh, 66k tris. The Retopo object at this moment has 12k tris. I tested it and it seems to be working pretty fast under 2k tris. Luckily technically I can hide part of the model in edit mode, but is this performance actually expected on a PC build like this, or am I doing something wrong?

[vxlcoder]

Thanks for the screencapture, @Shaggy90! Your performance is much worse than I would expect to see...

Would you mind sending that .blend file to us so we can do run comparative benchmarks on our machines? You can send it to retopoflow@cgcookie.com. My dev machine is much less capable than your machine, but I haven't seen that slow of performance on it with my test files.

Also, how recent is the 3.4.1alpha that you're using? We've made some minor changes recently, none that should improve performance much than what I linked in my comment above from 3wks ago.

[Shaggy90]

Hey, @vxlcoder, here is the file. I worked on Blender 3.6.2 and Retopoflow 3.4.1 alpha.

Edit: Sorry I missed your question about the recency of the build. I did use the one you linked here, but now I see you uploaded 3.4.1 to blendermarket. I tested it now though and it's basically the same.

[vxlcoder]

thank you for the additional details and the for! will take a look at this

[Shaggy90]

@vxlcoder Did you have a chance to check the performance of my file?

[vxlcoder]

@Shaggy90, I was able to take a look, and I saw the same performance issues that you posted about. again, thanks for sharing! I have been trying to consider how to approach solving this problem. below is a not-so-short summary, mostly me talking out loud and thinking...

the main issue is that RF is designed to work fine with 10k polygons, but not when there are that many on the screen at once. your blend file has a lot of geometry on the face, so operators that have snapping run really slowly (ex: polypen). this limit in poly count is due to some decisions we made many years ago that made solving certain tricky problems way easier, but with the limit on how many polygons we can work with at a time. Blender has no problem with that poly count, because it runs in c++ and can multithread, but RF is running in Python and cannot multithread.

we are planning a redesign of RF very soon (v4!), so I am debating waiting on large changes until then, but I understand the current frustration, and so I am thinking through some minor changes that could still have big improvements.

one simple-ish solution is to split the target mesh into two meshes: what could be worked on and what's not (both could still be rendered). this would require either the artist to indicate what's now getting worked on as they move around the mesh, or the code would have to make that decision somehow. you can kind of do this with hiding the parts of mesh that's currently occluded (options > visibility > hide...). this improves performance a bit, but it's still not great. the tricky bit with this splitting solution would be figuring out how to split and how to merge the two back together. also, operations that edit geometry/topo at the boundary/interface where the two halves connect (ex: tweak, loopcut) become trickier.

I need to think on this a bit more and run some tests to see how to solve this well.

in the mean time, you can try doing the split / merge on your own by duplicating the target mesh, deleting the vast majority of the geometry, and then retopo'ing the rest. just take care around that interface where they join back up! when you're ready to combine, merge the two meshes into one, and then merge verts by dist.

[Shaggy90]

Thank you for the in-depth explanation. I guess the assumption of 10k polygons was good enough back then, but today 100k+ characters are becoming a norm, especially with UE5 Nanite being available, so I'm glad you're redesigning it with v4. In this project specifically I was aiming at Mortal Kombat 11 mesh density and the face is pretty much the same density as in the game. Mortal Kombat 1 releases in a few days and it's probably even denser now.