Render Error in MH v1.3.0

[Ricardo2020]

To those who do the coding...

I have encountered a problem that has been around since MH v1.2.0 concerning rendering. Below is a resized GIMP mosaic of six images taken from different angles on the default base model and rendered with standard default settings. The only enhancements are subdivisions and symmetry enabled on the main toolbar.

Rendering error in MH v1.3.0

This issue is of note because it cropped up and was fixed in 1.2.0 via driver updates from nVidia on my main 'station. The problem persisted on my Apple iMACs. I never tested it in Windows since I run W7 on my production boxen.

However, in v1.3.0 the issue has reappeared and is persistent on all my Linux Mint Cinnamon Virginia (Jammy) machines, including an Apple iMAC that has been reloaded with Linux Mint. I have also tried it on Linux machines with the standard Intel PCH setup and it is evedent there as well. Thus, I am thinking this is not an nVidia driver issue.

The really interesting thing about this error is this: when the advanced rendering function is enabled with the lightmap turned on, the render is as it should be, without the error. This has baffled me no end since I lack the deep knowledge needed to dive in and find a solution.

What I want to know is this:

Is this issue evident on other machines belonging to other folks?

Has anyone found a solution to mitigate this problem?

If so, what steps were taken to solve the issue?

Many thanks for any and all advice on this.

[Ricardo2020]

NVidia released an incremental update to the 535 driver for Linux Mint on the date of this posting.

I had hopes that this newer driver would resolve the issue described above but it did not. The problem still persists. Basic rendering has mouth and eye cavities visible. As before, if advanced rendering is enabled and the lightmap box is checked, the render is OK. This only happens on MH v1.3.0 .

I am still at a loss as to why this is happening because I can duplicate the error on any machine running the Jammy fork. The Focal fork running MH v1.2.0 does not have the issue, even with the newer 535 driver. It is the same driver that the Jammy fork uses.

Any ideas?

[tomcat]

NVidia released an incremental update to the 535 driver for Linux Mint on the date of this posting.

On Win 11 (NV Quadro RTX) exactly the same situation.

[Ricardo2020]

Thanks for the insight, Tom. This helps a lot. It makes isolating the problem much easier.

I would be curious to see how it goes on an AMD Firepro machine with the Jammy fork.

I have a newer Dell Precision with a Firepro 5100.

It is in its travel case, so I will need to get it out, set it up, run the updates and then put MHv1.3.0 on, and run the tests...

[Ricardo2020]

Welp, I just got finished installing the Jammy fork of Linux Mint Cinnamon (Virginia) on the c2017 Dell Precision which has an AMD Firepro W5100 GPU with 4GB of VRAM. The CPU is an i7 with 16GB of system RAM. Needless to say, it runs like a scalded hound dog trying to get away from a rabid Sibirian tiger.

After installing MakeHuman v1.3.0 and doing a test render, I noticed that the issue discussed above is present on this box as well.

Seeing that both the green and red teams are presenting the same rendering error, I can safely say it is not hardware brand related. Although it might be software related, I think we can safely surmise that drivers are not to blame, neither are the various OS's.

What I can say with a small degree of certainty is that it has to do with OpenGL. Since this is a runtime that is not hardware dependent at the HAL layer, I am assuming that it has to do with the way OpenGL is reacting to some Python structures within MakeHuman.

This is a real head scratcher, folks...

Any thoughts?

[Ricardo2020]

I have ran extensive tests on all the boxen currently on my LAN to try and figure out what is going on with the rendering engine in MHv1.3.0, and have concluded that all of them present the error discussed above.

What I have NOT done is run the v1.3.0 on a Focal fork machine. Those rigs like v1.2.0 and run it flawlessly. I did notice that iMACs running this older config also present the rendering error.

Thus, I am flammuxed as to the cause, be it a kerfuffle in the drivers or OpenGL vs Python at the HAL.

Of note is the recent release of Python numpy v2.0 which has yet to slipstream into the Mint Jammy fork as an update. Mint is one of those distros which likes to take tings slow and easy in order to remain totally stable on the widest selection of kit. It might be a while before this change happens on my gear since Mint is our preferred OS.

I would be interested in what happens when numpy gets updated. Does anyone here run a Linux distro which has the new version of numpy, and is the error presented on such a setup?

[Ricardo2020]

Python 3.1 came down the pike today. After the update, I checked MHv1.3.0 running on Linux Mint Virginia (Jammy fork) and the rendering issue is still there.

I do not think the problem is with Python. There is something goofy about the way OpenGL is handling the rendering, since this library is common to Linux, Windows and MAC, which all present the same fluke. I am at a total loss to come up with a solution or workaround.

So, my question is: why does basic rendering present the fluke while advanced rendering with lightmap enabled works without issue?

[Ricardo2020]

I have a real problem going forward in the Community unless I ca get the rendering issue straightened out.

I was trying to get things going right today with a lot of troubleshooting which ended up with an uninstall and reinstall of v1.3.0 since I can no longer get the older 1.2.0 reinstalled and running on Mint (Virginia - Ubuntu Jammy fork). My earlier Mint (Una, Focal fork) was taken out by a drive crash. I have most of my assets, models and targets backed up, but I cannnot open the models or render new ones without the problems being discussed.

I noticed that, when in Advanced Render with Lightmap checked, I no longer see the body cavities but I did notice that the transparent ends of the long hair are not transparent, they are gray, as seen in the screenshot below:

v1.3.0 advanced render with lightmap

One needs to look close at the hair ends. See all the opaque gray which should be transparent? It is as if the issue is reversed in the two render modes. In basic, things are transparent that should not be, and in advanced with lightmap, things that should be transparent are opaque. If I disable the lightmap, it acts the same as the basic mode with body cavities showing. Why is this happening?

The rendering issues have completely stalled my work with the program. I am still wrestling with getting the Blender stuff running, but that is going to take a lot of time and effort. The effort is not a big deal, but the time lost is. Not only is all the work I did in the earlier version now useless, the newer version has rendering issues which have no solution that I can find, which make it useless as well.

Some help would be greatly appreciated.

Thanks in advance.

[joepal]

My take on this is that it is yet another indication that the old code base needs to be replaced with a modern version (ie the one that PunkDuck is working on). The now close to two decades old 3d engine in MakeHuman builds on an OpenGL version which is beyond ancient and only randomly supported by graphics cards.

I very much doubt there will be a fix for the 1.3.x or 1.2.x code bases which would a) be within reach, b) improve things significantly and c) not break about as much for a lot of users. The main issue here is "a". The only way to fix the core 3d issues would be to rewrite large parts of the underlying 3d logic from scratch, which is a huge undertaking.

You could take a look at http://www.makehumancommunity.org/wiki/ ... oks_broken although I doubt it'll help much.

My recommendations would be to help PunkDuck out with getting the new MH version up to speed asap. And/or use MPFB in the mean time.

[Ricardo2020]

I am grateful for the insight, Joe.

Looking at the OpenGL problem, I think you have hit the nail square on the head. New drivers are throwing spitballs at old code. This is why Tomcat and I are seeing the rendering problem. It makes perfect sense, and so there is no fix for the issue other than what you mention, to help develop the new version while diving into Blender and MPFB.

In the mean time, I have installed Blender 4.2 after removing an older 3x version. I have plugged in MPFB2 and it is ready to be configured with the required assets, which is going to take some time due to the large number of files in my collection, both mine and those by others. Since neither version of MakeHuman works as intended, I shall be migrating my files into Blender and removing the instances of MkeHumman v1.2.0 and v1.3.0 to avoid duplicate files.

Once I have all that Blender stuff going, I shall jump on Punk Duck's new code to see how it goes. I will keep the Community informed of my progress and note any snafus along the way. It is going to be a lot of work, but I enjoy such a challenge.

Again, many thanks.