bf-blender / Windows (2004/07/13) Updated (LSCM)
Moderators: jesterKing, stiv
-
- Posts: 0
- Joined: Sat Mar 22, 2003 10:45 pm
I shall condense my amazement and joy for all these new features into one word :
Oooooooooooooh !!!!!!
I have a small question/problem - do the old texture map to things (mix, multiply, add, subtract) still work in the same way ? It's just that one file I have has (procedural) textures that behave quite differently in the render in this new build (and also the distributed rendering build) than it used to. It's hard to describe the exact problem, I could upload a .blend if you like.
Thanks for continuing to provide these builds !
EDIT : I have found the exact nature of the problem. It's rather obscure - textures multiplying alpha ignore alpha generated by previous textures on materials with alpha set to zero. That probably doesn't make much sense so try this...
Add a new material to a mesh, give it alpha of zero. Add a texture, make this affect the alpha using mix. Then add a second texture, make this multiply the alpha. In 2.33a and earlier, you will still see something in the render. In these latest CVS releases, you won't.
Admittedly it's not exactly a huge error, but it is proving irksome loading older .blends that fake volumetric cloudy stuff with the dupliframes technique.
Should I report this to the bugtracker or is it better to report bugs in the release thread ?
Oooooooooooooh !!!!!!
I have a small question/problem - do the old texture map to things (mix, multiply, add, subtract) still work in the same way ? It's just that one file I have has (procedural) textures that behave quite differently in the render in this new build (and also the distributed rendering build) than it used to. It's hard to describe the exact problem, I could upload a .blend if you like.
Thanks for continuing to provide these builds !
EDIT : I have found the exact nature of the problem. It's rather obscure - textures multiplying alpha ignore alpha generated by previous textures on materials with alpha set to zero. That probably doesn't make much sense so try this...
Add a new material to a mesh, give it alpha of zero. Add a texture, make this affect the alpha using mix. Then add a second texture, make this multiply the alpha. In 2.33a and earlier, you will still see something in the render. In these latest CVS releases, you won't.
Admittedly it's not exactly a huge error, but it is proving irksome loading older .blends that fake volumetric cloudy stuff with the dupliframes technique.
Should I report this to the bugtracker or is it better to report bugs in the release thread ?
-
- Posts: 0
- Joined: Wed Oct 30, 2002 11:50 am
- Location: Nantes ;) France
- Contact:
hello all ;)
Salutations,
Thanks Gabio
I don't know if it's logic but the property debug don't work when the GameEngine is in textured mode ?
Thanks Gabio

I don't know if it's logic but the property debug don't work when the GameEngine is in textured mode ?
Re: hello all ;)
working well here. see if the "D" toggle after you property is set on, in logic windowsCaptainJeje wrote:Salutations,
Thanks Gabio
I don't know if it's logic but the property debug don't work when the GameEngine is in textured mode ?
-
- Posts: 0
- Joined: Wed Oct 30, 2002 11:50 am
- Location: Nantes ;) France
- Contact:
in logic windows D is on,
In Bounding Box, Shaded and Textured mode the property debug don't trace anything but in Wireframe and Solid mode i get my property trace in the good corner
Why the debug don't work in these mode (Bounding Box, Shaded and Textured mode) ? Perhaps it's completely normally but don't really logic
In Bounding Box, Shaded and Textured mode the property debug don't trace anything but in Wireframe and Solid mode i get my property trace in the good corner

Why the debug don't work in these mode (Bounding Box, Shaded and Textured mode) ? Perhaps it's completely normally but don't really logic
i finaly got fedora2 to work on vmware. So if i can get a building environement quickly i'll be able to provide both next time. It was just some error from me: i didn't selected other 2.6.x linux kernel. and in xorg.conf i didn't set depth to 24: which is my current depth in windows. Both have to be equal for x to start. I know i don't need X. I just like gnome...
Re: bf-blender / Windows (2004/07/13) Updated (LSCM)
Bug with 'Shift - D':
In most of situations, blender crash when i:
- duplicate a subsurfaced mesh, go in 'edit mode' and go back in 'object mode',
- then i try to select the original mesh (used for the duplication) to go in 'edit mode'.
If i use 'Alt - D' rather than 'Shift - D', it work fine.
So i think there is a bug in the creation of the mesh with the 'new crease' fonction.
_Ph_
In most of situations, blender crash when i:
- duplicate a subsurfaced mesh, go in 'edit mode' and go back in 'object mode',
- then i try to select the original mesh (used for the duplication) to go in 'edit mode'.
If i use 'Alt - D' rather than 'Shift - D', it work fine.
So i think there is a bug in the creation of the mesh with the 'new crease' fonction.

_Ph_
Yes there is something wrong. I have a slightly different problem but deals with same:
- create a cube and add subsurf
- switch to objet mode
- create a duplicate with ShiftD
- select the original again
- enter editmode and duplicate the original with ShiftD
- switch to objet mode again
- try to select the first duplicate that was created in object mode, Blender crashes
I submited the bug to the bugtracker.
- create a cube and add subsurf
- switch to objet mode
- create a duplicate with ShiftD
- select the original again
- enter editmode and duplicate the original with ShiftD
- switch to objet mode again
- try to select the first duplicate that was created in object mode, Blender crashes
I submited the bug to the bugtracker.
Has there been some change in the mapping of textures? In a recent render with the new build, it doesn't seem to take into account XYZ offset mapping the same as in prior builds. The file I was rendering had a blend texture to simulate snow caps on a terrain mesh & now it covers the whole mesh.
I'm going to have to rework a lot of open projects if this is permanent, as I rely heavily on procedurals & precise mapping.. Is this to stay, or is it some strange quirk brought on by a new feature?
edit: There's been a lot of great progress otherwise, the creasing feature seems to be quite cleaned-up compared to what I've seen in tuhopuu & such. Thanks again.
edit 2: Now I'm not certain if the mapping was the problem, something has changed though. Possibly the shaders (Oren-Nayer/CookTorr in this case). I've resorted materials in the stack - the hierarchy there has never made sense to me - and maxed out the Oren-Nayer roughness & now have results similar to what I had originally. BTW, the previous "correct" render was back in late May of this year, sometime just after the introduction of ambient occlusion I believe.
I'm going to have to rework a lot of open projects if this is permanent, as I rely heavily on procedurals & precise mapping.. Is this to stay, or is it some strange quirk brought on by a new feature?
edit: There's been a lot of great progress otherwise, the creasing feature seems to be quite cleaned-up compared to what I've seen in tuhopuu & such. Thanks again.
edit 2: Now I'm not certain if the mapping was the problem, something has changed though. Possibly the shaders (Oren-Nayer/CookTorr in this case). I've resorted materials in the stack - the hierarchy there has never made sense to me - and maxed out the Oren-Nayer roughness & now have results similar to what I had originally. BTW, the previous "correct" render was back in late May of this year, sometime just after the introduction of ambient occlusion I believe.
Last edited by crsrma on Wed Jul 21, 2004 6:53 am, edited 3 times in total.
-
- Posts: 0
- Joined: Sat Mar 22, 2003 10:45 pm