Weird 1.0.6 crash+error message
Weird 1.0.6 crash+error message
This happens to me every time I throw anything a little complex at 1.0.6. Always works fine with 1.0.4
- Attachments
-
- Error.jpg (142.4 KiB) Viewed 3162 times
I do remember Nik said he was tighten up some XML stuff and that Indigo
is more strict now. With that being said and looking at your screenshot
with all the "Ignoring degenerate triangle" warnings I would say you
have to wait for the updated exporter. You could try, just for curiosity,
to disable 'normal smoothing' on all meshes and try to render again.
<rant>on</rant>
Frankly, I hate all this crap about normals. When I do use OBJ, what I
do use the most because it exports so incredible fast, I often have a
shitload of bad normals and the only way to fix this right now is to use
the XML export of the meshes. It creeps the shit out of me because it
takes ages to export. That's what annoys me the most about Indigo
right now and since I use it.

<rant>off</rant>
edit: Bertrand, it happens even to "simple" scenes. Take a look
at this scene - another problem - but I can't render it with v1.0.6. *doh*
take care
psor
is more strict now. With that being said and looking at your screenshot
with all the "Ignoring degenerate triangle" warnings I would say you
have to wait for the updated exporter. You could try, just for curiosity,
to disable 'normal smoothing' on all meshes and try to render again.
<rant>on</rant>
Frankly, I hate all this crap about normals. When I do use OBJ, what I
do use the most because it exports so incredible fast, I often have a
shitload of bad normals and the only way to fix this right now is to use
the XML export of the meshes. It creeps the shit out of me because it
takes ages to export. That's what annoys me the most about Indigo
right now and since I use it.



<rant>off</rant>
edit: Bertrand, it happens even to "simple" scenes. Take a look
at this scene - another problem - but I can't render it with v1.0.6. *doh*
take care
psor
Last edited by psor on Mon Feb 18, 2008 6:59 am, edited 1 time in total.
"The sleeper must awaken"
@SmartDen
It's not your fault that it renders in v1.0.4 but not in v1.0.6. As I said,
Nik changed, or better say, made Indigo more strict about geometry.
So now the exporter devs have the problem that they have to figure
out whats going on ...

Hopefully Nik can invest some time into blendigo to help out with
finding the solution. This is truly an annoying restriction!

take care
psor
It's not your fault that it renders in v1.0.4 but not in v1.0.6. As I said,
Nik changed, or better say, made Indigo more strict about geometry.
So now the exporter devs have the problem that they have to figure
out whats going on ...



Hopefully Nik can invest some time into blendigo to help out with
finding the solution. This is truly an annoying restriction!


Indigo v1.0.5 Announcement wrote: Changelog:
1.0.5
* added check for degenerate triangles when loading meshes
* fixed deadlocks on linux
* reduced smallest autofocus dist to 0.0001 m.
* Made it so that Indigo can be executed from any directory without failing to find inifile.txt etc..
* adding region rendering
* updating settings print-out a little
* made splat_filter and downsize_filter accessible from inifile and renderer_settings
* added --pack for scene packing
take care
psor
"The sleeper must awaken"
i think i got it! try to remove double vertices. it works for me for this scene
I don't have double vertices, only vertices that are very close to each other, which you need when modeling in sub-d.
This "additional check" seems like a strange thing to introduce if it only really makes Indigo more intolerant of some geometry. And if scenes render well in 104, I don't think I can be bothered to check all objects in my scenes just so that they run in 106. Especially if I'm not sure what's causing it...
This "additional check" seems like a strange thing to introduce if it only really makes Indigo more intolerant of some geometry. And if scenes render well in 104, I don't think I can be bothered to check all objects in my scenes just so that they run in 106. Especially if I'm not sure what's causing it...
The funny thing is, in the scene that SmartDen and me mentioned
occurs another error message then yours Bertrand:
use OBJ export, I get a similar 'warning message' in the console
output but it's rendering.
should be glad about it. I hope Nik can give us some more insight.
take care
psor
occurs another error message then yours Bertrand:
And another funny thing is, always when I do render my scenes, as I said Ierror message wrote: IndigoDriverExep: SceneLoaderExep: ModelLoadingStreamHandlerExep: Normal was not unit length. (In element 'mesh', around line 679, column 5)
use OBJ export, I get a similar 'warning message' in the console
output but it's rendering.
Quit interesting that Indigo is so strict about XML but not OBJ, I guess Iwarning message wrote: Warning: Normal does not have unit length; normalizing
should be glad about it. I hope Nik can give us some more insight.
take care
psor
"The sleeper must awaken"
yes these checks are annoying because it doesn't seem necessary and it trips up on scenes that have had no real problem previously...or apparently so
I encountered this before and I traced it to a normal with a length of -3.9999
in the end I remade that part of the model and it was then 4.0 and deemed acceptable
previously it had 2 extruded edges meeting whereas in the redo I cut away a cube to give the same shape - at least that way I figured the sides would definitely meet exactly
I guess it has something to do with the proximity of vertices not necessarily doubles
I can understand that a plane has to be planar but it would seem to be too strict in its current implementation
what a degenerate triangle is I am not sure...
I encountered this before and I traced it to a normal with a length of -3.9999
in the end I remade that part of the model and it was then 4.0 and deemed acceptable
previously it had 2 extruded edges meeting whereas in the redo I cut away a cube to give the same shape - at least that way I figured the sides would definitely meet exactly
I guess it has something to do with the proximity of vertices not necessarily doubles
I can understand that a plane has to be planar but it would seem to be too strict in its current implementation
what a degenerate triangle is I am not sure...
a shame that noone really takes interest in whats going on in the c4d sub-forum 
polygons are degenerate when:
* the polygons area = 0 (you have to check it before exporting, i did it in cindigo. isn't that much slower. to find out how to calculate the area search with google)
* two sides of the polygon !> the third (this case cant happen in c4d, dont know if it can happen in other apps, would be stupid...)
after implementing this n cindigo i had no more problems with it. should'nt be too hard!
hope this helps...

polygons are degenerate when:
* the polygons area = 0 (you have to check it before exporting, i did it in cindigo. isn't that much slower. to find out how to calculate the area search with google)
* two sides of the polygon !> the third (this case cant happen in c4d, dont know if it can happen in other apps, would be stupid...)
after implementing this n cindigo i had no more problems with it. should'nt be too hard!
hope this helps...
There is a feature inside Blender API that normalizes normals automatically. I have done this in the exporter that I maintain.
If you get a chance can you try it and see what kind of messages Indigo gives you BbB (or anyone else with this error) when you try the hybrid exporter? Thanks
If you get a chance can you try it and see what kind of messages Indigo gives you BbB (or anyone else with this error) when you try the hybrid exporter? Thanks

Last edited by Wedge on Mon Feb 18, 2008 8:53 am, edited 2 times in total.
Content contained in my posts is for informational purposes only and is used at your own risk.
Who is online
Users browsing this forum: No registered users and 3 guests