I tried to import an obj-model and nothing happens. Bryce 5.5 doesn't crash, nothing. I can continue working but the model isn't there. At first I thought the model might be corrupt. But when it happened a couple of time to different obj models, I opened Bryce 5.01 and there I could import the same obj with no problem at all. I thought of reporting it to Daz, but in the bug tracker report it asks for the version of Bryce 5.5 (5.512 etc.), so therefore I opened the "about Bryce 5.5" window in Bryce 5.5 under "help" to see which version of Bryce 5.5 they mean????? Once that credits-screen opened, I can only close Bryce with alt-control-delete. Tried it a few times, happened each time. Anybody else encountered these problems? I did put the Bryce 5.5 update. Windows XP, 1.7 Ghz, 512 Ram, 120 gb disk

Forgot to add, it doesn't happen with every object-model, just with certain ones (that load in Bryce 5.01 with no problem).

Hmmmm.. Report this Please...It cant get fixed unless you do... It was Reported Earlier and Different Machine specs would be nice...

I did report it just now. Just thought maybe its just me :-) Right now I import these specific objects in Bryce 5.01. Save them as obp. Than get back to 5.5 and import the obp. Works.

Sounds like something I've run across in 5.5 - the OBJ importer no longer works with floating point data that is exponated. A lot of apps, to cut down on file size, use something like "3.24E-6" instead of adding all the leading zeros. The easist fix for this is to load it into UVMapper and turn right around and export it.

Can we get Cast Iron Flamingo to update Grouper?

There is absolutely no reason (other than laziness or idiocy) to not support exponentially-notated real numbers. That's not something that needs fixing - it's something that should have never been touched - ever...

Okay, alright, mistakes happen. (but hey, your objs load into 5.5 perfectly Robert) ;o) ----------------- "Can we get Cast Iron Flamingo to update Grouper?" He just e-mailed me the other day...

That's because I use UVMapper on my objs. ;)

The secret is out...;o)

btw, I've noted this as a bug - at the very least the error needs to be trapped and an error dialog displayed rather then just doing nothing!

I have the same proble, correction "HAD" couldn't import obj objects. Everytime i tried i got a little error window pop up with "?????4????" and the ok button that was it. CD (It has more blowfies than a well used outhouse)

System Specs Folks...?

I've actually had a similar problem in Bryce 5.01 though recently. It's been when trying to import some of the meshes made in Arboro. But I didn't know whether that was Bryce or not, some would import into C4D and not Bryce but would come into Bryce after being in C4D. Others simply come up empty anywhere. Only adding this in case it gives some perspective for bug fixers that it may not be totally 5.5 related?

Hey, Creations, can you tell me please what are objects in question: DAZ model(s), freebies from the web or something you made ? :)

Hm, the objects I tried myself, were our own models (made in Amapi), worked fine in Bryce 5.01. I tested it a few times to make sure. No problem with the 3ds or obp format, only the obj.

The objects that don't import in Bryce 5.5, I imported flawless in Bryce 5.01. Saved them there as OBP, than imported the obp in Bryce 5.5 and exported again in Bryce 5.5 as object. Afterwards the new object loaded ok in Bryce 5.5. I checked if are ALL our Amapi based obj- models have the same problem, but some import fine.

Message edited on: 05/03/2005 04:58

I asked becouse sometimes when UV mapping is not proper Bryce gets confused, but same model works fine, after beeing processed with UVmapper... Dunno, definetly some kind of Amapy thing which was possibly ignored in 5.1 and screws up 5.5 cuz DAZ changed OBJ importer or something...:( Is UV mapper reporting anything unusual when you load your models into it ???

UVmapper states upon loading such objects: "The model you have loaded contains out of range UV coordinate data. Would you like to correct this?" Upon clicking yes and saving the file, the object loads perfectly in Bryce 5.5. Thank Kemal!

No problem :D Daz studio used to export some models like that... As I can remember, it is beeing corrected by UV Mapper but UV mapping in Bryce is/was all screwed up, it does not matter for your own models if you gonna map it in UV Mapper for the first time, but it does if model in question already had UV mapping/coordinates (like Victoria character) or if U did UV mapping in AMAPI yourself (does Amapi have UV mapping?) :) I heard this was actually export problem with DAZ studio and it was fixed later, it might be UV export error in AMAPI as well, check it out on Eovia (is that maker of Amapi?) webpage/forums for updates/fixes... Good luck ! :D

It's not such a problem for me, now I know how to repair it, but happy to know Daz got it fixed! Daz: "It turned out to be a problem with how negative indices were handled in the OBJ. It has been fixed and will be available in the next patch release".

Problem being is we paid for Bryce 5.5, which should have been beta tested before it was released. Here we are finding bugs in it that the beta testers should have found before DAZ released it. My question is what were the beta testers doing, playing with it or not doing anything at all. CD (What are we paying beta testers)

I think that the beta testers were playing with something... ;) (that's a joke, no offense meant). Just as lack of exponential notation support is ridiculous, so is incorrect indexing of negative indices in OBJ files. It is friggin' simple. My Wavefront code not only handles negative indexing (correctly), but also line commands (which I interpret as splines). This is not rocket science and all of the information to parse the format is freely available online. Do I have to step in here and check their development work? ;)

Are some of these Models Saved in a Previos Version of Daz Studio...? Like Really early versions...? The Only reason why I ask is because there was an issue with Earlier Versions of DS and saving as OBJ and then opening up in a newer Version of DS...

Don't mean to offend but suggesting that the beta testers were some how to blame for these problems is rather a cheap shot, since most beta programs have an NDA that prevents them from defending themselves.
Beta testers get paid? I'd like to be in one of those! Usually the only compensation they get is a free copy of the program - that seldom covers the many hours that beta testers put in testing.
And how do you know that these bugs weren't reported?

Message edited on: 05/05/2005 11:48

I am not complaining. I think they did a great job on it. I also think betatesters can't find everything, as there are many different systems. The problem with the objects I had only with our own objects (wrong UV coordinates). That Daz fixed it this fast is really great news to me (as I handed many of our own models out and would hate it they wouldn't work, because we mapped them wrong). Bryce is new to Daz. I think an upgrade like 5.5 with a few patches is a great way to learn on the program and release a fantastic Bryce 6 in the near future I hope. I"ll be supporting Daz for that!

Yep...

Yep and sometimes I cant stand to see Everybody who worked so Hard On Bryce5.5 get bashed so Hard...We are Talking SOME "Legends" in The Brycing Community that Helped Betatest Bryce5.5... Even a few previous Developers/Programmers....! Everybody at DAZ must be Totally Calm because seeing the Bashing that Bryce and DAZ have gotten in the last few Days... Ahhh got to hate them NDA's...

Yeah Can I get Paid to Betatest too... Heck I would Make it a Living if I could...

Didn't you just couple of days ago said in another thread that EVERYBODY gets laid...err paid :P I bet "legends" were paid, and the rest of them got zilch !!! :P

As Dan has said... Nda's Stink... But a Program is a Program...

NDAs are part of business. I don't blame the beta testers. I blame the programmers. And I saw a huge list of them. Do they not understand the Wavefront OBJ file format? Is Bryce's code so noodly that its implementation was misconstrued? I assume that they acquired the source code for Bryce with the purchase thereof and it wasn't in opcode format throughtout... If they reeeeealllly need it, I can post my Wavefront parsing code (in C++) so that they can gain an understanding of how it should be accomplished. (Not trying to sound arrogant, but this is something that requires a little testing and even less coding to implement). Bryce must have one hell of a mangled import system for the developers to miss exponential notation (alright, I have to say it, something that is supported in C using any of the standard library stream/string methods) and bungle negative indexing. Negative indexing is simple: In addition to counting vertices down from the top of the first list in the file, you can also count vertices back up the list from an elements position in the file. When you count up the list from an element, the reference numbers are negative. A reference number of -1 indicates the vertex immediately above the element. A reference number of -2 indicates two references above and so on. That's all folks...