Page MenuHome

Triangle count is incorrect when above around 2 billion
Closed, ResolvedPublic

Description

System Information
Ubuntu 17.10

Blender Version
Broken: 2c347ebbba9

Short description of error
Triangle count is incorrect when its too large

Exact steps for others to reproduce the error

  1. Get high resolution tree and make it into bounding box mode
  2. create particle plane
  3. increase particle count until the triangles get above 2billion approximately
  4. notice how the number of triangles goes into the negative.

This happens on production scenes --

Event Timeline

This is actually a problem on verts and faces aswell, not just tris.

Stephen Swaney (stiv) triaged this task as Needs Information from User priority.

Please attach a .blend showing the problem.

This sounds like integer overflow.
A signed integer has a maximum value of roughly 2,000,000,000. Go over that and you get negative numbers.

  • MISSING INFO

Please follow our submission template and guidelines and make a complete, valid bug report, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.

A guideline for making a good bug report can be found here: https://wiki.blender.org/wiki/Process/Bug_Reports

Marking as "Incomplete" until the requested information/data is provided.

Carlo Andreacchio (candreacchio) raised the priority of this task from Needs Information from User to Needs Triage by Developer.Nov 18 2018, 10:12 PM

Probably not the most efficient bug blend, but its there. make sure you have enough ram to open the file (not a problem in blender 2.7)

Philipp Oeser (lichtwerk) triaged this task as Confirmed, Medium priority.

Overflow confirmed.

@Sergey Sharybin (sergey): does this have to be changed to long (or whatever) all over the place? DNA_mesh_types etc?

Never use long! It is platform specific and different on different OS/bitnesses. Use uint64_t in the statistics. Doing this in DNA_mesh_types is hell of a lot of work, which will involve modifying all the areas which loops and indices those.

Quite sure avoiding overflow in stats will solve 99% of cases. And quite sure once you've got mesh with more than 2B vertices you'll have other issues.

P.S. Do you expect me to work on this?

This isn't to do with one mesh but a scene... I opened our production scenes from blender 2.7 in 2.8 and it's reporting it.

The difference lies with 2.8 counting each particle instance in the tri /vert / face count rather than discounting it entirely.

Not sure who should work on it but it does occur in normal scenes for us.

If any more info is needed please let us know and we will clarify as soon as possible

Carlo

think I checked and me_eval->totloop was overflowing already, but will have a second look...

@Philipp Oeser (lichtwerk) if that thing is overflowing, then drawing will not be correct. And the modifiers, or anything. That's very weird and dangerous if that thing is overflown.

@Sergey Sharybin (sergey): yep, my bad (will stand in the corner for a while...), was something else overflown, checking this again atm...

@Philipp Oeser (lichtwerk), my bet would be on SceneStats from info_stats.c. Change int to uint64_t would be the first step. Second one would be to ensure correct format in SCENE_STATS_FMT_INT is used.