maestro,
Inregards to hanging when loading fonts, yes. I have Japanese, Korean, and english fonts on my computer, and it allways hangs a little when its loading fonts. So the more you have the longer it will take. Once its finished loading fonts, then it only takes a second to finish loading.
It shouldn't have any issues though.
Upspring 1.54
Moderator: Moderators
Hello...
latest Upspring manual available now in file universe :)
http://fileuniverse.com/?p=down&a=/spri ... ip&id=4065
regards
latest Upspring manual available now in file universe :)
http://fileuniverse.com/?p=down&a=/spri ... ip&id=4065
regards
Maestroy, I've read through it.
Methinks you should make a step-by-step "how to keyframe" for noobs, and talk about the BOS output... remember, there are a lot've people who are going to want to get from "rigging a tank" to "making my tank move in a non-screwed-up-way" and here are a few other minor quibbles:
There are a few points about smoothing / general issues I should note:
Importing all the objects seperately to maintain smoothing groups isn't necessary. Instead, use a uvmapper or 3D software that can split faces. UVMapper Pro, for example, can both split and weld things per angle. Very handy.
There are a few things that people that don't use Max should be aware of:
1. If you export your entire model as one OBJ file, you will not be able to import into UpSpring correctly, because UpSpring does not recognize OBJ hierarchy data.
2. If you export as 3DS, and whatever software you're using (for example, I use Rhino3D) doesn't recognize hierarchies, then you will need to properly set your base parent object in software that does recognize hierarchies. For example, I use Milkshape3D to set my base parent, and re-export my 3DS file as my final step before importing into UpSpring.
And I'd probably talk about DDS export using GIMP, since a large proportion of your audience is using Wings because it's free, and GIMP... because it's free. Also, I didn't see any notes talking about the technical differences between DDS DXT1 , DXT3, and DXT5 (the only DDS types that, to my knowledge, always work reliably in Spring). It's important that people understand that you can use DDS DXT1 with a 2-bit alpha, for example, as their colormap for glow/reflective/blue/transparency, and save on size/bandwidth, and that ALL DDS FILES USED ON S3O MUST INCLUDE ALL MIP LEVELS or they will not draw reliably on all end-user's systems.
Methinks you should make a step-by-step "how to keyframe" for noobs, and talk about the BOS output... remember, there are a lot've people who are going to want to get from "rigging a tank" to "making my tank move in a non-screwed-up-way" and here are a few other minor quibbles:
There are a few points about smoothing / general issues I should note:
Importing all the objects seperately to maintain smoothing groups isn't necessary. Instead, use a uvmapper or 3D software that can split faces. UVMapper Pro, for example, can both split and weld things per angle. Very handy.
There are a few things that people that don't use Max should be aware of:
1. If you export your entire model as one OBJ file, you will not be able to import into UpSpring correctly, because UpSpring does not recognize OBJ hierarchy data.
2. If you export as 3DS, and whatever software you're using (for example, I use Rhino3D) doesn't recognize hierarchies, then you will need to properly set your base parent object in software that does recognize hierarchies. For example, I use Milkshape3D to set my base parent, and re-export my 3DS file as my final step before importing into UpSpring.
And I'd probably talk about DDS export using GIMP, since a large proportion of your audience is using Wings because it's free, and GIMP... because it's free. Also, I didn't see any notes talking about the technical differences between DDS DXT1 , DXT3, and DXT5 (the only DDS types that, to my knowledge, always work reliably in Spring). It's important that people understand that you can use DDS DXT1 with a 2-bit alpha, for example, as their colormap for glow/reflective/blue/transparency, and save on size/bandwidth, and that ALL DDS FILES USED ON S3O MUST INCLUDE ALL MIP LEVELS or they will not draw reliably on all end-user's systems.
Hi Argh... thx for the feedback :)
Actually I plan to include Gimp but... I download the latest 2.2 beta and it dont work in my comp (freeze when scanning font)
I will review it once I got a working one.... maybe Ill should try older 2.0
Ill update it ASAP...
As Wing... DIE DIE DIIIIEEE!! i hates it
about UV, I ve tried UVmapper classic, Lightwave and MAX-5 and non seem work.... how to do that ? (smoothing separation ?) or Upspring smoothing is UVmapper pro monopoly ?
Actually I plan to include Gimp but... I download the latest 2.2 beta and it dont work in my comp (freeze when scanning font)
I will review it once I got a working one.... maybe Ill should try older 2.0
Ill update it ASAP...
As Wing... DIE DIE DIIIIEEE!! i hates it
about UV, I ve tried UVmapper classic, Lightwave and MAX-5 and non seem work.... how to do that ? (smoothing separation ?) or Upspring smoothing is UVmapper pro monopoly ?
As soon as I've sorted out the licensing issues and gotten my current work to where I think it should be... yeah, I can probably look at that for you, and give you a lot of feedback. If you want to see a pretty complex animation COB for a walkscript... that, I definately have. Reverse-translating it to OPK on the other hand, is gonna be a royal pain, especially as my work is actually intended to not go the static, timeline/framebased route, but instead allows for dynamic event timing for ease of maintenance- a further extension of the Zxswyg methods in NanoBlobs.
We're talking at least another week, though- sorry, I am in the middle of a major set of projects, and this animation stuff is one of several goals. Please be patient with me on this- I have taken up more than my usual "workload" here recently
There are minor issues with rotations in this version, btw. Anything past +/- 90 degrees seems to cause odd angular corrections, and I see a lot've values go to non-zero numbers (bottom-level floats or tiny offsets, but it's still not exactly zero) when I have not changed them. Nothing I cannot work around, of course, but they may be part of the problem that others have experienced. I'm very happy overall with where this build's functionality is, though- stepping into this after previous ones was like going from the very early particle code to CSimpleParticleSystem- it's a lot closer to where I'd like it to get, and the only major feature that's missing besides getting the animation output cleaned up is mesh-deformation instructions...
I have some ideas about how to address that for efficiency and flexibility purposes, but I just haven't had time to write out the long-winded post, with illustrations, to demonstrate what I'd like yet, and I'm not sure if anybody is going to want to make the changes to the COB interpreter the model format that I'd really like to see, instead of jumping to a new animation format (I am still unconvinced this is really necessary- especially as I get farther along with making advanced COB stuff work, btw).
We're talking at least another week, though- sorry, I am in the middle of a major set of projects, and this animation stuff is one of several goals. Please be patient with me on this- I have taken up more than my usual "workload" here recently
There are minor issues with rotations in this version, btw. Anything past +/- 90 degrees seems to cause odd angular corrections, and I see a lot've values go to non-zero numbers (bottom-level floats or tiny offsets, but it's still not exactly zero) when I have not changed them. Nothing I cannot work around, of course, but they may be part of the problem that others have experienced. I'm very happy overall with where this build's functionality is, though- stepping into this after previous ones was like going from the very early particle code to CSimpleParticleSystem- it's a lot closer to where I'd like it to get, and the only major feature that's missing besides getting the animation output cleaned up is mesh-deformation instructions...
I have some ideas about how to address that for efficiency and flexibility purposes, but I just haven't had time to write out the long-winded post, with illustrations, to demonstrate what I'd like yet, and I'm not sure if anybody is going to want to make the changes to the COB interpreter the model format that I'd really like to see, instead of jumping to a new animation format (I am still unconvinced this is really necessary- especially as I get farther along with making advanced COB stuff work, btw).
It doesn't have to be pretty or complicated, just something so I can compare the output of the BOS exporter with a working BOS script of the same animation.
The rotation thing is because the rotations are stored in a different format internally (Quaternions, some weird way of describing rotations in such a way that you cannot possibly imagine how it works. You can only work with their mathematical definitions)
Just know that if the angles suddenly seem to jump to other values, they still represent the exact same orientation.
The rotation thing is because the rotations are stored in a different format internally (Quaternions, some weird way of describing rotations in such a way that you cannot possibly imagine how it works. You can only work with their mathematical definitions)
Just know that if the angles suddenly seem to jump to other values, they still represent the exact same orientation.
UpSpring is not putting names of textures into 3DO files properly. It's impossible to make a new texture, (say, "foobar.tga"), and then apply it to a model. While I can add it to the list, etc., and that works just fine... the end result is not.
When the mod is run, Spring replies that it cannot find "texture 00", which means that it's not getting named properly when saving as 3DO. Minor problem, but rather annoying. And it only seems to happen with textures that are 100% percent new- if I use a texture that was previously defined elsewhere, it works. Why is this happening? Is there a way around this? I do not want to have to build a massive GAF just to work in a few new textures in a mod with a lot of 3DO files that I'm not converting yet, frankly
[EDIT]
Hmm... I just opened up the resulting 3DO in Notepad. The names are there. Methinks that Spring is borking it, not UpSpring. So much for that theory...
When the mod is run, Spring replies that it cannot find "texture 00", which means that it's not getting named properly when saving as 3DO. Minor problem, but rather annoying. And it only seems to happen with textures that are 100% percent new- if I use a texture that was previously defined elsewhere, it works. Why is this happening? Is there a way around this? I do not want to have to build a massive GAF just to work in a few new textures in a mod with a lot of 3DO files that I'm not converting yet, frankly
[EDIT]
Hmm... I just opened up the resulting 3DO in Notepad. The names are there. Methinks that Spring is borking it, not UpSpring. So much for that theory...
Oh! I found it! The darn thing is appending the "00" at the end of the names! Aha! That's why they look perfect in UpSpring, but don't work in Spring! So all it needs to do is not append the 00 that ends a texture name, or modders need to have a version of the texture that's named "mytexture" and "mytexture00". Simple enough.
Ah, and here's the funny-funny part.
I have a texture named "treadlong.tga" and "treadshort.tga". Note the no "00".
They load up perfectly in UpSpring. Absolutely no problems. And Spring loads them up perfectly, after reporting that it cannot find "texture 00" not once, but twice. I don't even need the versions with the "00" appended. Ok, what's going on here? Why do we even need the "00" before the ".filename_extension" anyhow? And why is this working perfectly, but returning error messages?
Aha!
Here's what's up: if I use the non-"00" versions, then UpSpring applies the texture name correctly, but Spring still borks finding it. However, if I include the "00" version, then Spring finds it, just fine, but returns an error message. This is all very, very weird... but at least I can see my textures now.
I have a texture named "treadlong.tga" and "treadshort.tga". Note the no "00".
They load up perfectly in UpSpring. Absolutely no problems. And Spring loads them up perfectly, after reporting that it cannot find "texture 00" not once, but twice. I don't even need the versions with the "00" appended. Ok, what's going on here? Why do we even need the "00" before the ".filename_extension" anyhow? And why is this working perfectly, but returning error messages?
Aha!
Here's what's up: if I use the non-"00" versions, then UpSpring applies the texture name correctly, but Spring still borks finding it. However, if I include the "00" version, then Spring finds it, just fine, but returns an error message. This is all very, very weird... but at least I can see my textures now.
It all started with converting GAFs to bmp's... spring needs to be able to load "x00.bmp", when the 3do stores "x"...
Upspring should be loading the x00 version, and then storing the name "x" for internal usage so "x" would also get saved in the 3do... but maybe there is something wrong with that.
It's probably easiest if i just remove any trailing "00" before saving to 3DO.
Upspring should be loading the x00 version, and then storing the name "x" for internal usage so "x" would also get saved in the 3do... but maybe there is something wrong with that.
It's probably easiest if i just remove any trailing "00" before saving to 3DO.
Thanks! I'm sure a lot of people would find this useful- 3DOs can look a lot more sexy if they have decent custom textures, and UpSpring is a great program for working with 3DOs, in many ways, now that I know how it works. For my current project, it may save a lot of time on certain things, and I'm sure lots of other people would appreciate it, too.