- User Since
- Jun 4 2010, 10:34 AM (489 w, 1 d)
Apr 15 2017
I think yes, I made a link to this addon on the TVPaint forum: http://forum.tvpaint.com/viewtopic.php?f=26&t=9719 so people can find it.
Aug 30 2016
Aug 17 2016
Apr 2 2016
This .csv format import/export is also available now in Krita from version 3.0.
Feb 27 2016
Feb 22 2016
Feb 20 2016
Feb 18 2016
Feb 17 2016
Jul 10 2014
Also, maybe if you zoom out it is not necessary to refresh at each frames, only when the cursor really moves (when 1 pixel > 1 frame)
Jul 5 2014
Is it the same for each sound/video file types? Because I can't reproduce it with http://commons.wikimedia.org/wiki/File:Examplevideo.ogv on Ubuntu 14.04 64bit.
Jul 4 2014
Just a guess but isn't it possible that the freetype library sometimes passes weird vector data? Usually 2D font rendering is very tolerant about self-intersecting curves, and font creators are not afraid to use it. Perhaps the truetype fonts are just not always Blender-compliant.
SSS is just a hack now in the internal renderer. AFAIK it renders the separate hidden side pass only from the camera's POV and only for the visible frame. I don't really know how the mirrored image is calculated but the offscreen part of the object's hidden side is missing there.
In most 64 bits systems, C long is 32 bits only.
Jul 1 2014
@Campbell Barton (campbellbarton): I can't try your solution (I've Linux), but it seems good.
Jun 24 2014
Are you sure the domain is completely transparent when rendering into the image file? All colors are different so perhaps it's some color space problem? (premultiplied alpha?)
Jun 20 2014
Ok, I can confirm this. Go to the node editor, compositing nodes, add a node (for example an Alpha Over), set a key on the fac value, then change the node name 'Alpha over' into something else. After this, in the dope sheet and in the graph editor, this channel has a red underline and this expression is visible there:
Jun 19 2014
I think there are a lot of other cases when the memory allocation explodes accidentally. If the swap memory on the harddisk begins to work because of this, it slows down everything dramatically. In this case, usually the only solution is to exit Blender immediately (if it is possible at all), and to stop and restart the swap space manually - with Linux, I don't know what about the other OSes. Or you can use ulimit but I've never tried it myself.
Jun 17 2014
I cannot reproduce it under Linux. Isn't it possible that window8 sends some fake/redundant buttonpress events here?
Another limitation: not interpolates between shape keys.
@Miika Hamalainen (miikah): sorry, I was not absolutely sure about that, but now I see you limited the recursion levels... a lot recalculations are possible but it's ok.
And by the way, I suspect this function has no protection against infinite dependency loops...
And @Miika Hamalainen (miikah), I think you can use copy constraint too. It's working with the null object here.
As I see it already does something with the constraint dependencies: scans the constraint list and call itself for all the target objects found. Perhaps this was the solution for the mentioned T34685 bug. It seems this function tries to replace the depsgraph with its own version... But I can imagine how complicated to do the same for all the possible drivers in the object...
In blenkernel/intern/dynamicpaint.c : subframe_updateObject() tries to update only the objects related to the moving brush, ie. parents, constraint targets etc. The driver targets are not processed here yet. Also maybe ADT_RECALC_ALL needed instead of ADT_RECALC_ANIM here.
Jun 16 2014
Linux: No crash, sometimes I get a "depth too large" message, but that's all. But if you click fast enough after Shift-B (or even press the mouse button before the key) there is only a crosshair to move and no selection rectangle. In this case after releasing the mouse button nothing happens.
Jun 15 2014
The problem is the WM_cursor_warp() function in editors/space_view3d/view3d_walk.c (and also in view3d_fly.c). The Wacom tablet works in absolute coordinate mode so warping the cursor to the center results wrong relative distances for the mouse events. I think the GHOST API needs a new function to check the possibility of warping - I don't think the GHOST internal check for this (window->GetTabletData()->Active != GHOST_kTabletModeNone) is usable here.
Jun 14 2014
Confirmed under Linux too.
This "mirror by values over value=0" is not the best name for the function... For example, mirror "X Global" means mirroring the object in the X global direction, using the YZ plane as a mirror. So here mirror "Value" should mean mirroring in the Value (Y) direction, around the Time (X) axis as a mirror. But instead, this function mirrors in the Time direction around the Value axis (2.71RC1).
@Bastien Montagne (mont29): I agree. Maybe the original curve intersects itself: it is not a problem for vector graphics, but wrong in Blender.
Jun 12 2014
I've found something, maybe related. I've checked the psys_cache_vgroup() calls in blenkernel/particle.c and blenkernel/particle_system.c . It seems all vertex groups caches are filled in particle.c together, except the PSYS_VG_DENSITY (it's in particle_system.c). When I played with the settings of the subsurf and the weight modifier, I've noticed that sometimes only the code part in particle.c called after a change so perhaps the PSYS_VG_DENSITY related things are not refreshed (but of course, perhaps nothing else refreshed, only the caches). By the way, since you already refreshing these caches, a comparison between the old and the new contents could trigger a deeper recalculation here.
I think the problem is that the arm is a two-bone IK chain and the IK target gets too close to the "tail" of the chain. Since the lower.L bone is longer than the upper.L, if the hand gets too close to the shoulder it is an impossible position with these bones. The two arm bones must have equal length to put the target near the shoulder.
Jun 11 2014
So, now I think the particle system needs a PSYS_RECALC_RESET flag to trigger a recalculation here. The program detects some changes in the deformVerts() function of modifiers/intern/MOD_particlesystem.c. But it sets the flag only if the number of vertices/edges/faces has changed (for example if the subdivision level changed). It seems there are cases when the number of mesh elements are not changed, only their structure (order of elements, referenced customdata?). An example if you apply the subsurf modifier.
Jun 10 2014
It seems the applied ("real") version is the wrong one... It's strange. Load this file, press the apply button on the subsurf modifier and try to explain what you see...
Open this file. It's the default cube with a subsurf modifier and a vertex group. In weight paint mode, you can see the additional vertices has interpolated color only (purple between red and blue). Maybe it's okay, you can see only the colors for the "real" vertices from the mesh. It's good for weight painting. But if you add a modifier after the subsurf (mirror for example), these vertices become "real" and gets the right color (ie. green) just like when you apply the subsurf modifier.
Confirmed (ubuntu 64bit, 517094a), the crash happens if you add a new Subsurf to the modifiers. The existing modifier is an Armature modifier with empty object field. The crash happens even if you delete the Armature modifier first then add the Subsurf.
Jun 9 2014
Where is the SQRT(2) in the original formula?
mods_hair-weight-edit.blend: I've removed all the beards and hairs and just checked the 'beard' vertex group in the weight paint mode. If the Subsurf modifier is enabled, the VertexWeightEdit modifier has influence on the 'beard' vertex group too, but only on the new subdivision vertices from the Subsurf.
@Howard Trickey (howardt), Thanks, that's because I know nothing about these algorithms :) But still, if there is linear interpolation somewhere in this code (for example you interpolate between two vectors), I think you could try to replace it with a polar coordinates interpolation.
@Howard Trickey (howardt), thanks, I imagine how hard is to solve this. What I mentioned was to handle the end of the edge at the corner as an arc around a central point. For example, you can calculate the central point, the radius and the angles for each edges and you can interpolate these values instead of linear coordinates. Interpolating in a polar coordinate system results arcs and spheres instead of lines and planes. For example, if the centres are matching and the radius is the same (cube corner) you can get a perfect spherical corner.
It's not easy to find a nice text color here. This is my attempt. @Bastien Montagne (mont29), could you check it please?O_O
@Ellwood Zwovic (gandalf3): You're right, I understand now. :D It's because the text colors are not changing. I confirm this too.
Jun 8 2014
@Ellwood Zwovic (gandalf3): Are you using the default theme? What are the colors at your User Preferences - Themes tab - User Interface - Value slider section? The color for the selected slider is the "Inner selected" here.
About these bevel bugs... It's just a feeling but I've not checked, but I think the modifier is using some kind of linear interpolation when filling the corners. Perhaps a polar coordinate system gives better result for the curves...
Something more information:
Blender is not a programming tool. But if you like Aptana, perhaps it is possible to make a plugin offering the possibility to execute a python script inside Blender. Perhaps Blender needs an extra interface to support this. But it is also a security risk.
It's actually working for me (the same 517094a on Ubuntu 64bit) but if I'm using this multi channel feature on the "Dimensions" block for the default cube, only the X and Z values are changing.
Jun 7 2014
@Tamito Kajiyama (kjym3): I've tried to set a new face flag in convertblender.c, forget it, not better at all. But choosing the best matching normal seems good even with, so here is my version to replace your FEdgeXDetector::getFaceNormal() :
Now I'm looking at your solution and thinking what is the best sign of a degenerate face. I think it's not important how the triangle behaves generally, only how it behaves in the calculation of its normal. Perhaps the length of the cross product vector (ie. the area of the triangle) is a good sign and it is calculated already in convertblender.c . Maybe you can put a marking flag there if (len < threshold). There are already such Freestyle related flags for the edges and the face mark. In my tests I observed that the degenerate triangles also have a valid but wrong normal vector. It was a very short cross product vector originally, enlarged to 1.0 length. But together with its floating point truncations and inaccuracies and this causes the wrong direction. But maybe this wrong vector still contains some information about the right direction of the normal.
Jun 6 2014
@Dean Connor (Unliked_Dean), your video card has only 256 MB memory. However this page (http://www.blender.org/download/requirements) says it is enough, actually sometimes it's not. Blender uses a lot of video card memory. Maybe the actual problem is something else here, but the video memory size is also a possible problem. And you are using a video driver from 2008, so first try to upgrade to the latest video driver from the AMD website.
So, after some debugging, this memory allocation boom happens exactly in the cycle beginning at line 531 of elbeem/intern/ntl_geometryobject.cpp in function ntlGeometryObject::initMovingPoints(double time, gfxReal featureSize).
Jun 5 2014
I can confirm this on Linux 64bit too. And the result is the same as "Shell" when the "Both" mode used. "Shell" mode runs away with the memory almost immediately but the "Volume" mode finishes quickly with low memory consumption (roughly 250 MB).
I can't reproduce it too (Linux 64bit 517094a)
@lyndon daniels (lyndon): this version has the same dependency loop, only extended by one additional armature object.
The problem happens when you control another object with bones from an armature and at the same time you control back the same armature with that object. It is an infinite dependency loop and Blender solves it with stopping after the first loop. It causes various artifacts, like a one frame delay in some bones movement.
It is a far too complicated armature to understand quickly, but I see you are using the NurbsPath.001 for spline IK in the skeleton on bone Neck.R and hooking the same spline to bones Neck.Ctrl and Spline.03_R.Ctrl etc. from the same armature. As far as I know the current dependency graph cannot handle this correctly. I've not tried it yet, but a solution can be perhaps to put the spline control bones into a separate armature.
Jun 4 2014
Unfortunately I think my solution is not correct with modifiers. The vertices must come from the derivedmesh, and not from the original mesh. But I don't know how to calculate the normal then.
About the better tesselation algorithm, I see how complicated the bmesh code now, so I don't expect too much about it. Probably most of the degenerated faces could be eliminated if these edge segments are handled the same way as the concave parts.
Jun 3 2014
Argh, there are other problems here. In line 2521 of this convertblender.c there is
Now I know the normals are calculated in the init_render_mesh() function of render/intern/source/convertblender.c. For the degenerated triangles of the tesselated ngons, this function gives wrong normal vectors. My question, why is it necessary to calculate the normals for each triangles individually? You get different normals only if the original ngon is not completely flat. If the triangles could use the normal calculated from the original ngon, 1) it's a speedup, 2) there are no wrong normals for the degenerated triangles.
Jun 2 2014
A new example file is here, as simple as possible. It is a plane with some subdivisions. If you render it, there is the problematic line in the middle and nothing else (tested with 517094a)
I have an idea to solve this...if the following is possible: I think this happens because during triangulation there comes some degenerated triangles where it is not possible to calculate the normals correctly. But there is the original polygon (what is triangulated) with a hopefully correct normal... Isn't it possible to use the original polygon's normal instead of calculating the normals for the generated triangles?
I can't confirm this, it is not a bug. What you see is only pixelated but basically the right mapping. It's because you don't have accelerated hardware GL on the virtual machine.
I'm not sure what is incorrect. I got the same result under Linux x86 with NVidia 610 card and the rendering is similar to the preview. It's very similar to your picture but the colors are blurred on the preview and not big solid pixels. Maybe because you have software GL only and it works this way. The texture is very low resolution (4x10 pixels) so its pixels are quite visible without interpolation. The colors of the previewed big pixels are sampled with subpixel interpolation and that's why not the same as the colors on the texture. For example, the bottom corner on the dragon triangle is the topmost corner on the texture. You see a big orange pixel there as a mixture of the yellow and red pixels around the corner.
Jun 1 2014
May 30 2014
It seems that the scaling factor is exactly 0.0001 in this case - maybe a value limitation somewhere in the code.
May 28 2014
If the object contains more than one isolated meshes, the first mesh calculated correctly but the others has this strange triangle net style. I've enlarged suzanne in edit mode to show what happened to her:
An example from the default cube:
Perhaps it redraws the whole view in every frame step? It requires 25 redraws/sec... For panning, zooming, modifying the curves etc. maybe a lower rate is quite enough. Maybe you can speed up the playback also if you redraw only the changed part at the cursor (if possible).
@Brecht Van Lommel (brecht): my drawing was about continuing the rays on the hidden side: not reflect them but just continue in the original camera-point direction because it is exactly what happening at the border of the black parts. If you need a normal vector for this, let it be perpendicular (or near perpendicular towards the camera) to the original s.I vector then.
@Brecht Van Lommel (brecht) : any camera movement ruins the illusion, it's like if you replace a mirror with a picture on the wall. Human eye is very sensitive to this, I think. So maybe you can simply leave out the hidden parts rendering. But if you render there something, it must be seamless.
Perhaps something like this?
@Brecht Van Lommel (brecht) : I thought the black is there because the rays are already go inside, that's why I recommended the flip for the normal. By the way, what is the color exactly at the border of the black parts? Is it an environment color? I don't understand why it is not on the black parts too.
Hello @Tamito Kajiyama (kjym3), thank you! I hope this finishes this bug. I cannot try it yet, the code review is not in the git. As a notice, I see a very similar part in convertblender.c at lines 3327 and 3366 for the CD_FREESTYLE_FACE marks, using the CD_ORIGINDEX again. Maybe it also needs a correction?
The black parts are the problem on the texture? It seems those are the parts hidden from the camera POV. If the rays reaching these parts, maybe they are reflected into the inside of the object so they cannot reach the light source. @dfelino: what happens if you invert both the ray and the normal vector?
it is working good with the Linux 64 bit c56bbcc version.
May 27 2014
I'm happy to hear it is not a general problem in Blender. Actually I didn't check the freestyle part... Thank you @Sergey Sharybin (sergey)!
@Bastien Montagne (mont29): I disagree, if you are using the keyup/keydown events to handle the modifier keys state, the mouse wheel is exactly the same problem. There are modifier flags in the keyboard/mouse events for a reason.
I think this is a design bug in the modifier system. The rB3182c54da6fd bug was the same thing. Now the modifiers must serve two different workflows at once. For applying it creates the customdata by itself, but without applying it passes a list about the edges mapping (and perhaps faces etc.). I think the modifier knows better what is what, so this postprocessing is not a good idea. It restricts design of future modifiers too. Was this originally a speedup to not copy all the data during the modifier chain but only reference?
A side effect. The mouse wheel works on unfocused windows too. Start two instances of Blender in Linux side by side. First map the ctrl-wheel and wheel events to something distinctive. Like zoom and pan for the 3D view. Press the Ctrl button and use the mouse wheel on both windows without changing the input focus. You will see that the focused window gets ctrl-wheel events but the unfocused gets wheel only.
May 26 2014
I don't know if it helps, but I've made some debugging with this MOD_boolean_util.c. The output DerivedMesh always contains the good freestyle edge customdata layer, but later (I don't know where) something overwrites this information. This happening after the modifier, and it rebuilds the freestyle edge layer (and perhaps others too) using the contents of the CD_ORIGINDEX layer as an index to the original mesh's edges. The exporter_SetEdge() function fills the contents of this index layer but it refers only to the original mesh (left) and not to the masking mesh (right).
@Sergey Sharybin (sergey) thank you! But something still missing. Now the edges are there from both objects AFTER applying the modifier, but through the modifier the edges from the masking object are still missing. Render my original example scene before and after apply to see the difference.
@mathieu menuet (bliblubli) Maybe you can try to restrict only the number of cores for OpenMP. I think it is not shared with the rendering performance settings. As default you can set the OMP_THREAD_LIMIT environment variable to limit the number of cores for OpenMP (sorry, I don't know how to do this in Windows). @Sergey Sharybin (sergey),@Brecht Van Lommel (brecht), is there a GUI setting somewhere in Blender to limit the max. number of cores for OpenMP?
The exporter_SetEdge() in MOD_boolean_util.c copies the edge customdata. It seems for me (but not sure, I apologize for the things below if I'm wrong) that CARVE_MESH_LEFT means the original object and CARVE_MESH_RIGHT is the masking object. But I don't know what CustomData_copy_data() copies here. Maybe this supposed to copy the edge customdata from the CARVE_MESH_RIGHT object? Because the CARVE_MESH_LEFT object's data comes from somewhere else. If I comment out this copy instruction the freestyle edges are still there (before applying of course).
In the sample scene if you change the Profile parameter of the modifier, the wild thing happens at 1.0 and 0.25 for me (better visible if you increase the number of segments). But some of the object's quad faces are not flat...
May 25 2014
I've found nothing OpenMP related but I have some notices:
The driver is working, even it is updating the gui button, so this is not a functional bug. I think the path is working from the driver to the button, but not backwards, right? Why not the driver sets the button state when it updates its displayed value?
Perhaps there is a race condition in the calculation algorythm when the cores overwrite each others data accidentally. It can be a bug in the code and happens because of an unfortunate asynchronous operation of the cores, so it is very random. I'm not sure this is the case here, but since you have a lot of cores - it is possible. Such a bug probably never hits a two- or four core system at all.
Also the "Add driver" option remains in the menu instead of "Remove driver". But it seems the driver is there and produces truncated (rounded towards zero) integers.
May 24 2014
If the user changes the input focus while pressing the modifier, I'm not sure you will get the press or the release event. The best is to use the state of the modifiers provided with the events. If you query the actual state from the OS maybe it is not the same as the state was when the event happened. If the keyboard or mouse event contains the modifier information, it is the best to use that. For example in X11, XButtonEvent, XKeyEvent and even XMotionEvent also contains the state of the modifier keys in the 'state' variable of the structure.
About the disappearing: do you think these objects were entirely missing, or just moved out of frame? For example if sometimes the object was still there but on a wrong position/rotation/scale. Also, I suppose this happens randomly and not repeatable.
I just guessing but if flickering/missing means wrong transform matrix and there are so many available cores maybe it is an OpenMP related bug in the preprocessing. It is just almost never happens on average systems with few cores. I see a lot of vector operations are parallelized in the code...
@mathieu menuet (bliblubli) so a single Blender instance rendering on a lot of CPU threads (160). Ok, thanks.
May 23 2014
Could you give some further details about the hardware? Was it GPU or CPU rendering?
Okay, then I say it seems the HSV<->RGB conversion used by Blender now works well only between 0 and 1. Above V=1, it is an extrapolation and goes to infinity quickly when converting from HSV to RGB. As you said, it is a display reffered space. You cannot display colors with V>1 correctly. But we need these cases too. For the rendering I'm sure Blender uses linear color space. In linear space the conversion is very simple and has no similar problem: V is always the maximum value of R,G,B, S is the minimum value and H is an angle on a color wheel.
May 22 2014
Isn't it possible that the higher floating point precision of the CPU (80 bits internally) somehow can result these? Some kind of butterfly effect...