Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: Scooby_Doo on September 17, 2006, 08:24:06 pm
-
Is there a reason why this is happening, besides the obvious poly error.
(http://img.photobucket.com/albums/v356/Shodan_AI/bad1.jpg)
This is what it's suppose to look like
(http://img.photobucket.com/albums/v356/Shodan_AI/bad2.jpg)
-
er... What are we looking at?
a.) only 3 parts are actualy modeled and showing (which means if you used Truespace you accidently clicked on those parts and saved the file, thus riuining the model and when you reload it only those parts are inteh model file)
b.) Only those parts of teh model are textured(or missing textures)... Either they are unmapped sections, OR teh texture names are messed up and you have soem that are correct so it looks splotchy...
Please define as the above screen is either of thsoe two cases... Luck!
-
I've reuploaded the truespace rendered picture again (you may need to force a refresh)
Everything is getting exported to the cob file and using the texture inspect there is a texture applied to them.
The medium sized blob is the cockpit and the other two blobs plus the missing pieces use the same texture.
-
I've never had that render window working correctly, and Kazan himself admitted it was merely hacked in. How does the model look in Modelview?
-
I've never had the texture work either, just white.. however the shape is correct...
Modelview shows the same thing, huge chunks are missing.
Oh my Modelview converts it correct
Anything I should be aware of from using modelview? Whats the scaling ratio?
-
i have a feeling its putting the polygroups in the wrong lods. convert scn files instead of cob. cobs have a tentancy to stick everything in a selection group, which ****s up hierarchy. converting a scn fixes this. cob files suck.
-
Nope sorry nuke, that produced the same results. :sigh: I also went back and collapsed all the objects (baring the cockpit) into one object and tried to convert just LOD 0 and still produces the same results.
Edit: I did my usualy routine to fix stack errors. (Create box then do a intersect boolean) Still produces the same result.
-
Try to rotate the converted model in modelview, and then look if some of the faces appear from the other side. I had this problem very often in the past, this is some sort of misunderstanding between truespace and PCS. Most propably those faces are flipped. Unfortunately, this isn't visible inside truespace, it always renders them.
-
It shows up as complete and non-reversed. I think I might be having some success with modelview with it. Is there any tutorials out there (search and google brought up nothing useful) to setup heirachy? I only need to know how to setup lod levels, the other stuff I can import through PCS.
-
That looks like it might be (intended to be) debris - is it?
Also, I'd advise caution when using modview to convert stuff. I've done a number of tests with simple and complex, small and large pofs - and NONE of them turned out right. IIRC, most of them lacked any sort of collision meshes at all, and the ones that did had massive errors in it. It might be less noticable with fighters though.
My strong advise would be to work out what's wrong with it when converting using PCS, and fix that rather than use modview.
As for hierarchy setup, I posted this in the lithunwrap 1.2 thread - at least the first of which you already glanced over. ;)
=> IPAndrews' Ship Creation Guide (http://underworld.fortunecity.com/pacman/106/fs2mods/shipcreationguide/convertingyourmodelusingtsandpcs.html)
=> Bobboau's PCS guide (http://freespace.volitionwatch.com/blackwater/fstut/fstut_index01.htm)
=> Karajorma's turreting tutorial (http://homepage.ntlworld.com/karajorma/FAQ/shipmods.html)
If they don't help, post the cob and I'll give it a look at if you like. Sounds like an interesting error. :D
-
Nope, I don't use debris on my stuff. I've already got those sites bookmarked a long time ago :D
Thats what I'm worried with modelview.
Heres the scene. http://www.badongo.com/file/1430917 (http://www.badongo.com/file/1430917)
-
Wow, err, I'm honestly surprised you got PCS to convert it at all. Mine just locked up and didn't respond, even if I leave it for 10 mins, which is longer than any other model I've ever converted.
Deleting all but the lod0 objects didn't help either, so something is very wrong with your basic geometry.
I think I know what it is too - in TS, select just about any face on your lod0 pieces and try moving it around. Especially on the port wing. It does this when I select and move random faces up:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Misc/GeometryGoSplat.jpg)
The faces are only partially - if at all - attached to their surrounding polys. Thus when PCS tries to convert it, it's encountering half polys, edges with no polys, disconnected polys, edges and verts - the lot. ;)
BTW, it's far better practice to build your models in one continuous mesh rather than chunk by chunk as you have here. For a start it's much neater, and you avoid issues like these, but it's also a lot more efficient and easier to bughunt/fix because you don't have to go shuffling through subobjects to find the one on which the error is.
I personally find it encourages more detailed meshes too. Ie, you begin to think in polys rather than chunks. ;)
Oh, and hierarchy wise you had everything but the lods named correctly. Lods should be detail0, detail1 and so on rather than detail-1a, detail-1b and so on. I think PCS might just run on whichever object comes first in the hierarchy though, so it probably wouldn't matter much.
-
I've found the cultprit! Sorry after removing subobjects till the mesh appeared correctly, I found it was cockpit glass that was doing it :wtf:
I've always used detail-1X, and pcs hasn't complained in the dozen or so models. Its the order in the cob file thats important, not their exact numbering. (same with sub lod turrets too)
As for using a single object versus multiple, I've found it to be the exact opposite. Try tracking down a bad part on a whole object rather than just a part of an object (i.e. remove all non-errorous parts). Also try building the model from one mesh, it'll take a lot longer than using seperate objects and it's usually easier to UVmap too. Also don't forget if you do weld them together you'll end up with more polys. Not to mention if I need to move/resize/delete a subobject it won't affect the others.
I should have done this from the start (we wouldn't have needed this entire thread LOL) I dread having to do it through, like having root canel drilled LOL
(http://img.photobucket.com/albums/v356/Shodan_AI/Ratoth.jpg)
-
Post disection time!
I've always used detail-1X, and pcs has never complained in the dozen or so models. Its the order in the cob file thats important, not their exact numbering. (same with sub lod turrets too)
Yeah, thought as much. The "detail#" format tends to be standard though, which is why I use it at least. :)
As for using a single object versus multiple, I've found it to be the exact opposite. Try tracking down a bad part on a whole object rather than just a part of an object (i.e. remove all non-errorous parts).
Thing is though, if you build your ships up as one piece, you usually have a pretty clear idea of where the error is going to be based on the complexity of the geometry in various locations, so in the very rare case that you do have a problem in geometry, you know where to look anyway.
I've never had any geometry errors worse than two faces using the same verticies, and even they don't make it past UV mapping. Certainly never geometry errors that crash PCS or modview during conversion or otherwise.
Basically, what you lose by not being able to delete pieces never matters. ;)
Also try building that model from one mesh, it'll take a lot longer than using seperate objects.
If it takes much longer, then you'd have to be doing something wrong. Attaching one piece to another takes a few seconds in any program I've used.
It's usually easier to UVmap too.
Why? There's no reason it would be easier that I can think of. Besides, UVing is really easy on just about every ship anyway!
Also don't forget if you do weld them together and ending up with more polys.
To do so on your ship with the wings, central spar and main hull pieces would add around 48 polys to your ship. I count 56 unnessecary polys on the edges of your port wing. ;)
Either way, it's not many polys at all, and the stability it brings is well worth it.
Not to mention if I need to move/resize/delete a subobject it won't affect the others.
You can box selecting groups of verticies and moving/re-sizing/deleting them quite easily. Again just takes a couple of seconds to select more complex parts.
And how often would you need to do that anyway, really?
-
Yeah, thought as much. The "detail#" format tends to be standard though, which is why I use it at least. :)
Someone must have used the "-" in the past while I was trying to figure it out. I hope pcs uses either detail-1 or detail-A (or something to that nature instead of 1a,1b, 1c.
Thing is though, if you build your ships up as one piece, you usually have a pretty clear idea of where the error is going to be based on the complexity of the geometry in various locations, so in the very rare case that you do have a problem in geometry, you know where to look anyway.
I've never had any geometry errors worse than two faces using the same verticies, and even they don't make it past UV mapping. Certainly never geometry errors that crash PCS or modview during conversion or otherwise.
Basically, what you lose by not being able to delete pieces never matters. ;)
I've found out, even with this one, completexy doesn't mean thats going to be whats causing the problem. For example, I would have been hunting all over the wings trying to find what caused it when it was the glass (which was quite simple) all alone. Divide and conquer.. Actually I've found when your UVing you can find erronous (sp?) polys rather easily, when something doesn't quiet fit in or is connected to wrong vertices, then theres a good chance you've got an internal useless poly.
If it takes much longer, then you'd have to be doing something wrong. Attaching one piece to another takes a few seconds in any program I've used.
Look at my creature meshes, try doing that with just one mesh :nervous: Wait a monent, are you just talking about mesh attach and not booleaning them together? If so then we're argueing about nothing then :lol: If your just joining that won't solve geometric problems.
Why? There's no reason it would be easier that I can think of. Besides, UVing is really easy on just about every ship anyway!
If your doing mesh attach, then we're on the same wavelengths, otherwise you'll need to do multiple mesh selects.
To do so on your ship with the wings, central spar and main hull pieces would add around 48 polys to your ship. I count 56 unnessecary polys on the edges of your port wing. ;)
Either way, it's not many polys at all, and the stability it brings is well worth it.
Again if your just joining meshes then theres no change. If you boolean, look at my creatures again, last thing you want to do is boolean all those spikes :shaking:
-
I've found out, even with this one, completexy doesn't mean thats going to be whats causing the problem. For example, I would have been hunting all over the wings trying to find what caused it when it was the glass (which was quite simple) all alone. Divide and conquer.. Actually I've found when your UVing you can find erronous (sp?) polys rather easily, when something doesn't quiet fit in or is connected to wrong vertices, then theres a good chance you've got an internal useless poly.
The cockpit was just a material fault by the looks of it, but the thing is here, that there are massive geometry errors in the wings, but having it split up into objects hasn't helped. ;)
Having it all one solid continuous object would likely have prevented said geometry errors in the first place, but wouldn't have affected the glass either way.
Look at my creature meshes, try doing that with just one mesh
I have (http://webzoom.freewebs.com/twisted-infinities-va/portfoliosite/Media/AesirShips/Outpost1.jpg) actually. ;)
(Ignore the terrible smoothing though. It's an old model.)
:nervous: Wait a monent, are you just talking about mesh attach and not booleaning them together? If so then we're argueing about nothing then :lol: If your just joining that won't solve geometric problems.
Heh, I take it you use 3ds max then? No, I did mean attaching them, but I mean something closer to booleaning rather than just Max's Attach button. (I say closer, because I don't really like booleans. I much prefer to do anything they would normally do manually.) :)
Incidentally, why don't you use the Max POF exporter if you are using max?
If your doing mesh attach, then we're on the same wavelengths, otherwise you'll need to do multiple mesh selects.
Thats easy though. And again the increased stability it brings is well worth it, along with better use of the available texture space, since everything rendered to the model will actually be seen rather than hidden inside another piece.
Actually, that reminds me of another reason for solid continuous meshes - shadows. If shadows are ever reintroduced in the way Bobboau originally designed them, multiple piece geometry like this will cause some really weird effects, since it works with solid or mostly solid objects.
Again if your just joining meshes then theres no change. If you boolean, look at my creatures again, last thing you want to do is boolean all those spikes :shaking:
For small extrusion details like that, no - there's no need to boolean them. Neither though is there a good reason to have them as an alltogether separate object from the hull. In such cases, the attach button in max is perfect. ;)
Using your model here as an example, were I building it I'd have the hull, engines, wings and cockpit neatly joined (meshwise) together, and then have the tiny details like the guns a part of the same object, but not nessicarily connected to the rest of the mesh. In max terminology, my rule would kinda be 'Boolean the big things, attach the small things'.
So by the time it's ready for conversion, PCS only has to deal with one piece of geometry rather than having to merge them all together just to create the hull as you currently have it do. That's likely where errors are going to arise.
I'm not worried though - as your models become more complex, I'm fairly sure you'll learn to merge them into one mesh for the same reasons I did. :p
-
The cockpit was just a material fault by the looks of it, but the thing is here, that there are massive geometry errors in the wings, but having it split up into objects hasn't helped. ;)
Having it all one solid continuous object would likely have prevented said geometry errors in the first place, but wouldn't have affected the glass either way.
I don't think it was a material problem, since it had only one simple texture thrown on it. Actually I used to have everything in one object but the stack fault errors drove me up the wall. Thats one of the reasons I quit merging them unless it's necessary (for shining maps). Plus it's much faster to leave them as is. I do merge objects that have a wide angle connection, but for tight corners or areas that are never seen, no sense waisting time. Oh ya, seperate objects make it easier to LOD, just delete.
Actually for the creatures most of the objects (not the spikes) will be merged into one object (for shine maps)
Incidentally, why don't you use the Max POF exporter if you are using max?
It never has worked for me, usually crashes.
Using your model here as an example, were I building it I'd have the hull, engines, wings and cockpit neatly joined (meshwise) together, and then have the tiny details like the guns a part of the same object, but not nessicarily connected to the rest of the mesh. In max terminology, my rule would kinda be 'Boolean the big things, attach the small things'.
So by the time it's ready for conversion, PCS only has to deal with one piece of geometry rather than having to merge them all together just to create the hull as you currently have it do. That's likely where errors are going to arise.
Yup large areas are booleaned together and trimmed, small or hard to see connections are left as is.. such as the base of the starboad wings.
I'm not worried though - as your models become more complex, I'm fairly sure you'll learn to merge them into one mesh for the same reasons I did. :p
Yup and then comes an error and you end up tearing it all apart again. :D
Edit: ugh i wish quoting was easier to do LOL
-
I don't think it was a material problem, since it had only one simple texture thrown on it.
Just tried a cube with that material applied, PCS interpreted it as no material at all (ie, it appeared solid red in modview). So there is definitely a problem there. :p
Anything the game finds no texture on will be completely invisible in game IIRC. So you'll actually have no glass over the cockpit if you try converting the model with that on it.
Actually I used to have everything in one object but the stack fault errors drove me up the wall. Thats one of the reasons I quit merging them unless it's necessary (for shining maps).
(The POF exporter) never has worked for me, usually crashes.
Ok, I'm beginning to think there may be something you're doing during construction that....'shatters' the geometry really badly as I demonstrated with the pic earlier. Add to this that you say the POF exporter always crashes, and the fact that you have to do a lot of error hunting - and something's definitely going wrong.
Also, if you're refering to the error in PCS where you get a message to the effect of 'Stack overflow protection was engaged', then I'm 100% certain that'll be because of this shattered geometry.
By splitting models up as you now do, you've certainly not fixed the stack fault errors - just gotten the number of them in each object down to something that PCS can just barely manage to work through - though it will often choke on a particularly bad bit.
I have absolutely no idea what could be causing such bad shattering, but if you've been having these sorts of crashes for a long while now, it sounds like it must be something you do with every or at least most models. Any ideas there?
Plus it's much faster to leave them as is. I do merge objects that have a wide angle connection, but for tight corners or areas that are never seen, no sense waisting time. Oh ya, seperate objects make it easier to LOD, just delete.
Lodding is a valid point for separate objects - but that's easy enough to do already by welding verticies together when talking about a single solid object. Likewise deleting all those attached but not mesh-joined pieces is easy enough without having those pieces as separate objects. :)
I'm not worried though - as your models become more complex, I'm fairly sure you'll learn to merge them into one mesh for the same reasons I did. :p
Yup and then comes an error and you end up tearing it all apart again. :D
I've never gotten any geometry errors more serious than the odd unwelded vertex or the like. As I said before - nothing's ever crashed for me because of a geometry error. You have to have really serious geometry faults for it to crash PCS.
-
i used to do solid meshes, then taylor got rid of all the bugs and freespace seems friendlyer tward multimesh and non-solid objects. back in the old days, i used to use *cringe* booleans to join sections. this caused problems. so i started doing the booleans on copys of the models i wanted to join, then created new virtices on the original and moved them to the same coords as the new ones created on the booleaned copy, after this i extruded and re-creades the section o wanted to attach. it was time consuming and always added way too many polys, but it worked really well for making a stable model. nowadays i just subtract the one model from the other, and remove the faces on the inside that you couldnt see anyway. its better for keeping a good poly order, thus allowing you to use transparency in the same model and texture without artifacts. the only ship i made that has any artifacts is the pb sepulture, which was booleaned together. save my first couple of models, ive never had any conversion trouble as shown in this thread. i attribute it to not hopping formats (which you have to do when using free modeling tools).
i still think that moving from per-subobject rendering to per-texture rendering would be a massive performance booster. things live vwep and heavily animated models would be better handled, as would capships with all their ****ing turrets.
-
But then I rebuild the glass reapplied the texture and it didn't complain, so who knows, vertex data could have been corrupted during the conversion from max->3ds->cob->pof. LOL Yes I'm quite aware of invisible objects, in fact I"m fixing one on the destroyer as I'm writing this :)
Well it's either shattered geometery, which STL modifier indicates no errors, or the more the rounding in truespace. Well if I find the bad one and redo it so it doesn't fail and everything looks good in fs2 then theres no error. :) Course if there are errors then merging them into one big object will just result in a big object with lots of errors then.
Well as for this error, I've had it one other time, with one of sagas ships. I think it was due to it being converted and reconverted over and over that broke something or flipped polys. I ended up just building a new one that looked like the old one.
Actually I haven't had the game crash in quite some time now... that was due to a dock pathing problem if I remember right. (course i shouldn't speak :nervous: LOL)
HORRAY At least I can read now that pirates day is over LOL
btw, is anyone having troubles login in to photobucket? It seems to stall here.
-
does anyone else hate how ts, any version, handles smoothing. you have to use a different material for each autofaucet level, and it never comes out right. most times you cant even tell the difference in game. i really want to get away from truespace.
-
OMG you read my mind :nervous:
I was battling that earlier tonight, I couldn't get my hunter frigate to smooth correctly, the bumped out panels were being smoothed and never could get it to show up right in modelview.
What I find much much much worse than that.... The complete devil in truespace is you have something selected in LOD 0 group, you go and select something someplace else and truespace insist you stay in LOD 0 group, unless you move up to the correct level You want to drag a turret into the lod level and it decides to pick something from your current level :ick: :mad2:
-
But then I rebuild the glass reapplied the texture and it didn't complain, so who knows, vertex data could have been corrupted during the conversion from max->3ds->cob->pof.
When I checked it, the cockpit glass suffered the same shattered poly syndrome as the rest of the model. Not hard to imagine that it just had it a bit worse than other parts of the model and thus caused the crash. ;)
Well it's either shattered geometery, which STL modifier indicates no errors, or the more the rounding in truespace. Well if I find the bad one and redo it so it doesn't fail and everything looks good in fs2 then theres no error. :)
No it just means there's no visible errors - the geometry itself is still shattered. If you want proof that this shattered geometry is present in game, just look at the attached POF. All I did to your original model is selected 7 random polygons from various places and moved them vertically away from the model and converted.
Of all those, only ONE poly on the right engine's top actually moved the geometry around it in the correct way. The rest display all sorts of errors, but the major ones that make it through PCS are the hidden, zero area polygons that are only visible when you move other polys around as I have here. I'd estimate your fighter has HUNDREDS of extra polygons in there that are invisible. :\
Course if there are errors then merging them into one big object will just result in a big object with lots of errors then.
The answer is to fix the errors - not just split it into objects to prevent the errors from crashing things. :p
Well as for this error, I've had it one other time, with one of sagas ships. I think it was due to it being converted and reconverted over and over that broke something or flipped polys. I ended up just building a new one that looked like the old one.
I've been converting my ships from .blend => .scn => .cob => .lum => .cob => .scn before converting, and still never had a crash. Converting alone rarely causes problems for most models. If the models have shattered geometry though, then converting them could very easily cause problems.
--------
i really want to get away from truespace.
Go for Blender!
If you like building via directly manipulating verticies in a wireframe, I've thus far found Blender to be nothing short of incredible in that regard. It gives you whatever degree of control you want, all through keyboard shortcuts, giving it a very fast workflow.
Eg, if you have a selected verticie you want to move around, you tap G to grab it.
From here you can move it around freely and quickly, but if you want differing types of control over it:
To snap it to pre-set grid incriments, hold Ctrl.
To perform tiny free movements, hold shift.
To perform tiny snap movements, hold shift and Ctrl.
To constrain it along any one axis, just tap the axis letter (once for the global axis, twice for local, thrice to de-constrain it).
To move around one pixel at a time, tap the arrow keys.
To enter co-ords manually, just start typing the number of the X co-ord, pressing tab to switch between axes. Enter sets, escape cancels, backspace deletes just the value in the currently active axis. (This is the only aspect that TS does better with the little object info window and how it can take sums. It's not really needed in that form in blender though, so it hardly matters anyway.)
To cancel the move, right click.
Most of those same control methods work for rotating and scaling too. If you forget the shortcut key of any of them, or want to see what else it can do, space brings up the quick-menu.
The new builds can export directly to .cob as well - so there is a good chance we may be able to do _everything_ in blender, bypassing all the conversions completely. I'm currently looking into this, and I'll write up a tutorial for how to do it if all goes well. :D
Oh, and it's also got an incredibly efficient rendering engine, which I've seen manage around a million of polys on an integrated graphics card with only minor chugging - which is awesome for high poly modeling. :)
[attachment deleted by admin]
-
a new annoyance in ts7, the coordinate box, if you want to change a value, you can no longer hilight it by double-clicking it, and if you dont type the new value in fast enough, resets it to its original value. its very annoying as i use the coordinate box alot. ts7 is also significantly less stable than ts6. other than that its full of useless features which i will never use.
il give blender a go. i like some of what you say about its vertice manipulation.
-
There are some great (if somewhat nerdy ;) ) video tutorials for it here: http://blender3d.com/cms/Video_Tutorials.396.0.html
The getting started ones (specifically the first two) are a must see, and will give you a very solid understanding of the overall ways in which blenders interface works. Once you get that down, you're set.
If you have any questions, just ask. :)
-
When I checked it, the cockpit glass suffered the same shattered poly syndrome as the rest of the model. Not hard to imagine that it just had it a bit worse than other parts of the model and thus caused the crash. ;)
Well this must have occured during the conversion because theres none on the main wing, i went through selected as many all but about 12 then hide them, select those 12 and hide those... Max reported 0 polys, 0 vertices
The answer is to fix the errors - not just split it into objects to prevent the errors from crashing things. :p
Mesh crashes pcs, divide mesh up into logical parts, remove one part from the build until you find which one causes the problem, go back and redo that part (i.e. fix that error, potentional delete it and redo it) then retry. I hope you see I am fixing the error, but first I have to find WHERE the error is.
I've been converting my ships from .blend => .scn => .cob => .lum => .cob => .scn before converting, and still never had a crash. Converting alone rarely causes problems for most models. If the models have shattered geometry though, then converting them could very easily cause problems.
Well this wasn't my model to begin with, it's been with saga for ages now, so who knows what's with it.. Although now most of it is mine :)
--------
I'm not sure we need blender, we'd be just replacing truespace with blender. I'd like to see plugins (for PCS 2) that support truespace, blender, maya, lightwave, and max seperately, so we don't need to go through all these conversations.
-
What we need isn't a modelling program rather we need a heirachry program. If we needed a modeling program we just use max/lightwave (i'm sure lightwave has an excellent vertex manipulation like max does)
-
Well this must have occured during the conversion because theres none on the main wing, i went through selected as many all but about 12 then hide them, select those 12 and hide those... Max reported 0 polys, 0 vertices
Have you done any subesquent conversions to TS that don't result in the shattering effect?
Mesh crashes pcs, divide mesh up into logical parts, remove one part from the build until you find which one causes the problem, go back and redo that part (i.e. fix that error, potentional delete it and redo it) then retry. I hope you see I am fixing the error, but first I have to find WHERE the error is.
Yeah, I got that and it's a valid practice, though you just plain shouldn't get those sorts of errors in the first place unless something is going quite wrong somewhere. ;)
However, you were making it sound like just splitting it into objects automatically fixed whatever errors you encountered while it was a whole object when you said "Well if I find the bad one and redo it so it doesn't fail and everything looks good in fs2 then theres no error."
That's what I was disagreeing with, because there are still errors. ;)
I'm not sure we need blender, we'd be just replacing truespace with blender. I'd like to see plugins (for PCS 2) that support truespace, blender, maya, lightwave, and max seperately, so we don't need to go through all these conversations.
You're missing the point here. :)
If we can do everything in Blender and skip TS entirely, that means we have a single, FREE program for building, texturing and getting models into FS, requiring no new tools or converters!
Yes you can do it with TS 3.2, but it's such a pathetic excuse for a modeler it's not funny.
Blender however is enormously powerful, and VERY flexible.
What we need isn't a modelling program rather we need a heirachry program. If we needed a modeling program we just use max/lightwave (i'm sure lightwave has an excellent vertex manipulation like max does)
Err, why would you need a separate hierarchy program when all modelers (even TS 3.2) have perfectly good systems? :confused:
-
The problem is not everyone uses blender. I personally use Max, theres people that use lightwave and maya here too. I've got blender installed, not too fond of it, I like max's setup much better.
Now maybe if we could convert from whatever we use to Blender then that might not be too bad, course we could end up with the same problems we do with truespace.
Well for me, baring shields I've got the mesh setup before I convert. I just use truespace to setup hierarchy, points and shield. Truespace doesn't even need any object modifiers (outside of shields) for all i really care (oh wait... except for translation/rotation/scale)
-
The problem is not everyone uses blender. I personally use Max, theres people that use lightwave and maya here too. I've got blender installed, not too fond of it, I like max's setup much better.
I'm not suggesting that if it works, everyone should immediately switch over to using Blender instead of whatever they were using before. No way.
If you like\know well TS, Max, Maya, Lightwave, or whatever just keep using it.
But what about peeps who want to use totally free AND totally legal applications to build models and get them into FS?
Currently they have to use TS 3.2 at least in part, which is utterly horrific and will scare off a lot of potentially brilliant new modelers.
However, if we can replace TrueSpace 3.2's role alltogether with Blender, then that would likely encourage more new people to continue modeling.
Well for me, baring shields I've got the mesh setup before I convert. I just use truespace to setup hierarchy, points and shield. Truespace doesn't even need any object modifiers (outside of shields) for all i really care (oh wait... except for translation/rotation/scale)
To be honest I would highly recommend working out what's going wrong with the 3ds max exporter rather than scraping it through TS. :\
-
I'm not suggesting that if it works, everyone should immediately switch over to using Blender instead of whatever they were using before. No way.
That'd be like trying to convert the fanatics over at CIC to FS2 :D :drevil:
But what about peeps who want to use totally free AND totally legal applications to build models and get them into FS?
Currently they have to use TS 3.2 at least in part, which is utterly horrific and will scare off a lot of potentially brilliant new modelers.
it's horrible interface scares some of us non-new modelers too LOL
However, if we can replace TrueSpace 3.2's role alltogether with Blender, then that would likely encourage more new people to continue modeling.
As long as we can quickly setup the heirarchy and convert I'm all for it.
To be honest I would highly recommend working out what's going wrong with the 3ds max exporter rather than scraping it through TS. :\
That plus turrets never show up correctly, their always at the origin (0,0,0), plus I'm not fond of the model setup for it. Baring the rare pcs grumbling at me, the 3ds->cob->pof format runs quite quickly. Btw I'm not the only one with the "error has occured, max must shut down" error.
-
it's horrible interface scares some of us non-new modelers too LOL
lol, yeah - I was using 3.2 for the first time a few months ago - just seeing what it could and couldn't do. It became quite apparent as soon as I imported one of my ships into it. Whenever part of the ship was supposed to go off-screen, the stupid thing just folded the offscreen part back on - using the edge of the screen as the fold line. Ouchies!
As for using Blender for quick and easy hierarchy setup, I'm not sure about it in that regard. I haven't really properly looked into it yet, but I'd say TS's is a bit quicker and easier to use. Still gotta do more tests.
-
i'm with Scooby... I use TrueSpace only for hierarchy. Everything else is 3dsmax8 (I love getting free legal versions from my robotics team!)
I'm working on trying to understand the plugin, but i haven't got it all figured out yet. So in the mean time, i have to go through truespace... :shaking:
-
i played with blender for an hour and i didnt like it. i dont like the way it tossed my uv data from the models i imported. if i had to learn a new program, id just put more effort into learning max.
-
Call me stupid, but I've found max to be one of the easier to use programs. Sure it's got tons of tech stuff that I have no clue about. But the basics isn't too hard. The interface is more standardized with Windows and is FAST, Blender was ok... truespace 3 is fast(albiet ugly), truespace 7 ungodly slow.
Plus moving around in a scene is more my style (scroll middle mouse = zoom, drag middle mouse = move). Also hit F12 to bring up type in values for trans/rotate/scale is a major plus.
-
its got alot of good **** i can use, ive just yet to get my brain wrapped around it all. ive actually started an installation model entirely in max, ive just yet to complete it. its just models i started in truespace id rather finish in truespace.
-
"Use the stack"... :D
The stack can be helpful, especially if you've realized you've made a mistake or don't like what you've done, just delete the stack entry and start over (especially if it's too far back to undo)
One area I'm trying to figure out correctly is nurbs, although the results seem to be always way too poly intensive.
-
Wow! It worked! After converting a Blender-generated COB with a single multipart turret heirarchy, we now have the first Blender -> Pof conversion!
It kept everything too - names, relative scales, centres, offsets, textures - the lot! :D
i played with blender for an hour and i didnt like it. i dont like the way it tossed my uv data from the models i imported. if i had to learn a new program, id just put more effort into learning max.
Blender definitely keeps the UV data - but since it handles textures\materials quite differently from TS, I don't think it will immediately apply them for you.
How differently I'm not sure - to be honest I've never really looked into it in any depth cos the old version I was using could only export DXFs. Now that I know Blender can export directly to cob ready for conversion AND can UV map models very well, I have the incentive to learn it. :D
Blender was ok... truespace 3 is fast(albiet ugly)
You're saying TS3 had a faster interface than Blender?! No way! :p
Plus moving around in a scene is more my style (scroll middle mouse = zoom, drag middle mouse = move).
I haven't been using max all that long - but I really don't like the view controls compared to Blender or even TS. It's mainly the holding alt + middle-click to rotate the view that feels awkward - is there a way to swap the pan and rotate controls?
-
You're saying TS3 had a faster interface than Blender?! No way! :p
Actually yes, truespace 3's interface is faster, blenders is a bit sluggish (but no wheres as bad as truespace 7) You must remember t3 is much older than blender and most likely written in C.
I haven't been using max all that long - but I really don't like the view controls compared to Blender or even TS. It's mainly the holding alt + middle-click to rotate the view that feels awkward - is there a way to swap the pan and rotate controls?
See the bottom right? The circle with three lines coming out of it? Arc Rotate Selected, this rotates the camera around the selected object (btw, when you click on it, it draws a yellow circle on the viewport, with four rectangles, those let you limit rotate to an axis). For panning use the hand next to it. The very bottom corner lets you toggle from one viewport to 4 viewports. Also ctrl+r activates rotate, however I find it's quicker just to click on the button in the corner instead.
Quick keys (that i remember at least)
l:left
t: top
b:bottom
c: camera
p: perspective
u :user,
z: zoom to selected (if none then zooms scene)
Edit: w: translate
Edit: e: rotate
Edit r: scale
x: toggles axis (allows you to lock on a specific axis)
left click: select (deselects if nothing)
right click: object properties and also hide/unhide/freeze/unfreeze
middle scoll:zoom
middle drag: pan
f3: toggles wireframe
f4: toggles wireframe (only works if object isn't in wireframe mode)
f2: toggles highlight selected
f9: quick render
f12 : type in trans/scale/rotate data (you can enter x,y,z values/%)
8: enviroment settings
0 : render to texture
alt - a: align
alt - z : zoom
g: toggles grid (i don't know offhand the snap to grid)
M : material dialog window
spacebar : toggle object/subobject lock (i.e. you can't deselect, or can selected items)
Edit Mesh quick keys
1: vertex
2: line (poly edge)
3: triangle
4: poly (can be adjusted for angles)
5: entire subobject
Added:
Shift followed by a translation/rotate or scaling will bring up a message box asking if you want to copy, inherit or a reference of the original
V: brings up the viewport menu (lets you select top/bottom/left/right/back/front/iso/persec/camera view)
general hints: once you've found the perfect persepective view, (must be in persepective mode) ctrl + c creates a camera at that position
Normally I just leave the main tool bar and command bar active, and disable the rest
As for blender
I don't like how the left click and drag will move the objects, it's too easy to click and accidently move something. How do you even pan in scene? I found the side, top, user, camera.. but it's missing left/right, back and bottom
-
I meant is there a way to rebind the controls, so middle clicking and draging rotates rather than pans - cos I really dislike having to press alt instead. Thanks for the quick key guide though. :)
Actually yes, truespace 3's interface is faster, blenders is a bit sluggish (but no wheres as bad as truespace 7) You must remember t3 is much older than blender and most likely written in C.
Blenders interface is as fast as your graphics card's OpenGL speed will allow - ie, instantaneous in everything unless you're running on a really dodgey integrated graphics card. :p
If however you were trying to do everything through menus and buttons rather than shortcut keys, only then would you be right. Unlike Max and TS, Blender encourages learning the shortcut keys from the start - just hover your mouse over nearly any button that has a shortcut key, or look through the spacebar quick menu and it will list the shortcuts for each function.
I know you can use shortcuts for everything in Max also, but it doesn't actively try to teach them to you, so learning them will be slower unless you know to specifically look for them.
---------
As for the view controls to view from the opposites of the side, top and front, just hold ctrl and press the associated numpad key. Eg, if you wanted a top view you'd press Numpad 7. If you wanted a bottom view you'd press ctrl+Numpad 7.
Rotating is just middle mouse
Zooming is scrolling or ctrl+middle mouse.
Panning is shift+middle mouse
The mouse buttons are reversed from what they do in other programs - this is just how the Blender coders like it by default, but it's a setting you can change quite easily by dragging the dividing line between the menu bar and your scene down. This reveals Blenders 'Options' window. In the 'View and Controls' tab, set the "Select with" option to be the left mouse button.
Also in here you can set blenders free rotation system to be 'track ball' or 'turntable'.
Max uses a turntable system - so when you rotate a model you can only rotate it on 2 axis. The track ball setting allows all 3, but is a little trickier to control.
-
Customize->Customize User Interface and have fun :) plus you can build your own toolbars it looks like. The mouse controls should be there, I've never touched them I'd get too confused if I did LOL
Also look at help->Hotkey map You can move your mouse over the key on screen to see what they control.
-
One word of warning... Using the optimize modifier can result in damaged/aka shattered mesh.
Oh add 'q' to the keylist. it set the mouse pointer to select only (no translate/rotate/scale)
-
So that was it? What was it supposed to do?
Btw, looked through the customize interface segments, and it appears to only affect keyboard controls - not the mouse. Doesn't matter though - 'tis just an annoyance, nothing more. :)
-
It optimizing the geometry.. but it can produce on occasion, some messed up meshes. Also theres a uv optimize, which does the same but attempts to maintain the uv map (i believe 8 is more powerful, you can target weld vertices and try to maintain uv map)
Sorry about the mouse, know what you mean when i used blender :D
One thing I wish you could do was completely customize the main toolbar. Theres several buttons (including hierarchy linking) that i never use and would love to replace with something more useful (like grouping). you can remove some of the controls but not the majority :blah:
-
I picked up on the fact that it 'optimises' stuff from its name, but I wanted to know what exactly that means it does to the geometry aside from shattering it. ;)
Looked it up myself, and ugh - it's an auto poly-reduction tool. Understandable for Lods, but why were you using it on lod 0? Or weren't you?
Sorry about the mouse, know what you mean when i used blender :D
Ironically, that seems to be nearly the only control you can actually somewhat configure in Blender at this stage. ;)
(In that same drag down hidden menu>view & controls, you set whether clicking the middle mouse rotates the view or pans it. It basically swaps the controls for panning and rotating around. Not exactly great, but I think it might have been put in to make max users a tiny bit more at home.)
I think I read somewhere that configuring the rest of the controls is slated for a future version.
-
It is sometimes useful for lod 0, especially after doing slicing. But now I do that mostly by hand using vertex targetting
-
Well I tried converting my essex cruiser cob file into blender, because it's extremely unweldly in truespace. Results weren't too pleasing for the eyes LOL All the turrets were placed at 0,0,0 and the hull i don't know what exactly happened there LOL
I was hoping it would work, this model is too messy and hard on the eyes with all the beveling to accurately place turrets.
-
For whatever reason, TS and Blender seem to ignore each other's hierarchy, centres and offsets, but PCS is able to read both programs cob outputs with all that stuff intact. Rather odd really. :\
You've already turretted the Essex in your screenshots though - why do it again in Blender?
-
The turrets in 3dmax aren't used. I don't convert them, instead i've already got the turrets setup in cob format. I just import the turret cob onto the model, position it, and renumber it and vola.
Although I wish there was a way of renumbering easier.... I've already got 20 turrets and still need to add the laser batteries :shaking: