Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

3 Dimensional Chat / Is GameSpace really what it's cracked up to be?

Author
Message
Benjamina
22
Years of Service
User Offline
Joined: 7th Sep 2003
Location:
Posted: 13th Sep 2003 13:43
Hi,

Just before I invest a couple hundred dollars to purchase it pre-release, I'd like to ask a question.

Is this program any good? Has anyone ever bought and used it?

Someone told me it was great and did things like nurbs and metaballs that could be converted over to meshes and animated and all that jazz.

I wanted to know if anyone had looked at it, and does it come with a manual like the other TrueSpace programs come with?

Thanks.

Regards
Benjamin

Many good things come in small packages
MikeS
Retired Moderator
23
Years of Service
User Offline
Joined: 2nd Dec 2002
Location: United States
Posted: 13th Sep 2003 19:40
Doesn't come out for another week or so I think. I'm really looking into it though. I already have T.S 5.2 though. Hopefully they'll have some sort of trial out really soon.



A book? I hate book. Book is stupid.
Richard Davey
Retired Moderator
24
Years of Service
User Offline
Joined: 30th Apr 2002
Location: On the Jupiter Probe
Posted: 14th Sep 2003 12:31
I'm not sure it's out yet, but I can't wait to see what they've got in store for us. Interesting they are partnered with the Milkshape guys, so hopefully that means good things.

Cheers,

Rich

The sky above the port was the colour of television, tuned to a dead channel.
Your brain's just like any other appliance: it works better if you plug it in...
Mentor
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: United Kingdom
Posted: 14th Sep 2003 16:41 Edited at: 14th Sep 2003 16:43
the main downside is I don`t see no reference to BSP on the site, you would think with what Truespace (their main product) does well and the fact that they aimed it at games developers, it would have inspired them to include the ability to compile a bsp, but apparently not, that either means it`s a seriously "kiddified" tool for rich kids to edit Quake models in, or they didn`t think it through, or they expect third party plugins to fill the gap, that implies they aren`t commited to making a decent tool, they probably think they can sell some simplified model editor for big bucks with their name attached and the "kids" who play games will buy it for status value, I was realy excited when I saw the news, but the more I look at the style of the website and the lack of details as to what it does exactly do, the more I feel I will need to see it up close and personal and read some reports from paying punters rather than picked comments from beta testers or people who may be on commision or whatever, I was bitten with Pro and the way over the top DBDN reports about it before release, they lulled my normaly cautious nature into a sense of security, that won`t happen again.

Mentor.
Ravey
Retired TGC Developer
23
Years of Service
User Offline
Joined: 2nd Nov 2002
Location: Southern TGC Nerve Centre
Posted: 15th Sep 2003 00:49
Milkshape doesnt export .x format properly so i'm going to get gameSpace. I have used trueSpace since it was called Caligari on the Amiga. It's one of those apps you either love or hate.

It is more geared towards character modelling so BSP wouldn't really feature.

Regards,
Dave Milton
Check out my games: Diode, Root, Binman & Skateboard Crazy
indi
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: Earth, Brisbane, Australia
Posted: 15th Sep 2003 03:26
Quote: "Milkshape doesnt export .x format properly so i'm going to get gameSpace"



[thats beagle snot mate]

http://www.lunarpixel.com
It's already tomorrow in Australia
Shadow Robert
23
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 15th Sep 2003 04:55
milkshape exports DirectX X bloody fine with JAT's JTExporter.
for DBClassic i posted a screenshot of what setting you use and a little blurb when it was asked last time, just doa search for it you lazy bugger.

gamespace ain't out yet, not a screenshot, not a demo, nothing... wait til its out before you starts asking waht the heck its like
because quite frankly no one can say.

personally though unless they;ve changed how trueSpace works totally it just ain't gonna be cut out for games development - sorry but trueSpace just never has been game friendly.

Mentor
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: United Kingdom
Posted: 15th Sep 2003 12:12
Ravey: I just checked an old coverdisk with truespace 4 demo on it (I was sure I wasn`t losing the plot ) and several of the examples like radiosity room are architechral and would not look out of place in Quake, Truespace can render scenes and buildings, not just models, since it can model them it would have made sense (IMHO) that they would have included BSP, it`s just another format to describe a 3D model with some extra vis data, if they where intending to make a killer gamers app that is, I am more suspicious that if they find this profitable they will release another "Gamespace", probably called "Gameworld", that does compile BSP and add that to the product range, why sell one overpriced app once if you can sell it twice?, if the publics dumb enough then they will do that, if the sales are sluggish they might add BSP in an attempt to attract the punters, if then the response was too enthusiastic then they may split it up into two different apps, pleading a need for specialised tools for each type of model (world or object) or some such drivel so they can sell you essentialy the same tool twice...with different compilers attached.

Mentor.
Ravey
Retired TGC Developer
23
Years of Service
User Offline
Joined: 2nd Nov 2002
Location: Southern TGC Nerve Centre
Posted: 15th Sep 2003 13:49
I sent examples to Mike who tested and confirmed that Milkshape was adding extra vertices. I had a test of 120 characters on screen which ran like a dog compared to blitz3d. Mike exported the same model from truespace and the fps doubled - beating blitz3d speed.

It is something to do with DBPro using the standard loader, Mike is going to write a custom loader in the future to handle this.

Raven - i'll got find and try that - thanks

Regards,
Dave Milton
Check out my games: Diode, Root, Binman & Skateboard Crazy
indi
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: Earth, Brisbane, Australia
Posted: 15th Sep 2003 20:42
sorry ravey so how many vertices were added and was this from 1.66?

http://www.lunarpixel.com
It's already tomorrow in Australia
Ravey
Retired TGC Developer
23
Years of Service
User Offline
Joined: 2nd Nov 2002
Location: Southern TGC Nerve Centre
Posted: 15th Sep 2003 21:07
np Indi
I'm not sure of the exact amount to be honest - but it halved the speed in the test. This was before v1.66 however, I'll run the speed test tonight when I get home with v1.66 and report my findings.

Regards,
Dave Milton
Check out my games: Diode, Root, Binman & Skateboard Crazy
JAT
23
Years of Service
User Offline
Joined: 7th Nov 2002
Location:
Posted: 16th Sep 2003 03:01
I'm curious about the connection of gameSpace with MilkShape, but can't seem to find any information on it other than the mention here and in a MilkShape forum, and the chUmabaLumsOft logo on the Caligari site. Anybody have the info?

My guess is that Mete helped them with all the exporters.

Since MilkShape doesn't do .bsp, maybe that's why they don't have it. Otherwise, the process internally of creating .bsp's is so different from normal modeling, that might explain the omission.

John Thompson
http://www.jtgame.com/jtedit
Ravey
Retired TGC Developer
23
Years of Service
User Offline
Joined: 2nd Nov 2002
Location: Southern TGC Nerve Centre
Posted: 16th Sep 2003 23:31 Edited at: 16th Sep 2003 23:32
Indi:

I ran a few tests displaying 100 objects at once.

Milkshape .x file - 14 FPS (jt exporter)
trueSpace .x file - 50 FPS

I've sent the files to Mike to have a gander at.

PS - i know the information presented is a bit light, I just thought I would report in as I failed to do anything yesterday due to beer and a very hot curry getting in the way of things.
I'll carry on experimenting...

Regards,
Dave Milton
Check out my games: Diode, Root, Binman & Skateboard Crazy
indi
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: Earth, Brisbane, Australia
Posted: 17th Sep 2003 11:51
Well I had to conduct a test on my own.

A simple cube in Milkshape v 165 produces 8 vertices before export and 24 vertices when imported back in from jt exporter when it was exported in binary mode and non binary mode.

Opening the exported file in Xview 1.5 results in 24 vertices as well.


John whats wrong with that mate?.

http://www.lunarpixel.com
It's already tomorrow in Australia
Richard Davey
Retired Moderator
24
Years of Service
User Offline
Joined: 30th Apr 2002
Location: On the Jupiter Probe
Posted: 17th Sep 2003 11:58
I'll be surprised if gameSpace includes a BSP compiler for the exact same reason that 3DS, Maya, Lightwave, SoftImage etc don't either! Doesn't stop modellers with those packages using them for games though. Right tools for the right jobs people and level design is either done in a 3D package (and then compiled outside of it) or done in a totally indepedant package.

Cheers,

Rich

The sky above the port was the colour of television, tuned to a dead channel.
Your brain's just like any other appliance: it works better if you plug it in...
indi
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: Earth, Brisbane, Australia
Posted: 17th Sep 2003 12:19 Edited at: 17th Sep 2003 12:35
test 1 is binary and test 2 is the ascii equivalent.
Ive supplied all the peices in this zip file.


is it adding more to help control uv mapping or is it a mistake in the exporter.

[href]www.lunarpixel.com/temp/Ms165_test.zip
[/href]

http://www.lunarpixel.com
It's already tomorrow in Australia
Van B
Moderator
23
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 17th Sep 2003 13:14
Perhaps Milkshapes import system is not that great - It might not be relevant but if you load a .X model into DBPro and convert it to a memblock, your data is in the same sorry state. A Cube, normally 8 vertices and 12 polys ok - converted to a memblock gives you 12 polys, but 36 vertices because each poly has it's own vertices. It could just be the way DBPro handles it's memblocked objects, but I can imagine it being a lot easier to do it that way than have a complex poly to vertice list inside the basic format. When I made the .x importer for VANmesh, I made an optimizer too, so the extra vertices are removed. 3D Exploration has an option to join the equal points, which not only plays a big part in smooth normals, but also reduces the vertice count. Not that you should ever use 3D Exp for .3DS to .X conversion (the little converter supplied with DBC is the safest option).

The thing that strikes me is the lack of advertising and information about this modeller, the demo is probably gonna be huge, so I'll have to keep checking the umpteen PC mags out there - but I'd seriously hold onto that cash until you've seen it for yourself.


Van-B

My cats breath smells of cat food.
indi
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: Earth, Brisbane, Australia
Posted: 17th Sep 2003 17:39
I just did a test with 3dcanvas and it spits out an x file with 24 vertices as well!

Could this be the norm? is it using 4 vertices per 2 polygons? or 4 vertices per face.

seems like vertice overkill unless vertices do something to textured faces or something to do with smoothing groups.


weird.

http://www.lunarpixel.com
It's already tomorrow in Australia
Van B
Moderator
23
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 17th Sep 2003 18:05
Ahh, there's a texturing consideration as well. I mean, if you have two identical vertices, but the UV coordinates are different, you can't delete that vertice and weld it - you can only remove vertices that have identical texture data as well as the vertice locations themselves. So if you had a cube, with standard default UV mapping, each side would have to be a seperate group because the UV data would'nt match at the corners, the only verts that could be removed is the corners of the poly split - meaning (insert sound of rusty cogs turning) - 12 polys gets turned into 36 verts, which could be optimised to 24 verts because each side can lose 2 verts.

AHHHHHH!!!!

That's it! - the UV mapping plays a part! - if the vertice UV coordinates don't match it can't remove them!. It's the only way it can import the model without losing data. That's why untextured models keep losing smoothing groups - the UV data keeps the mesh together.


Van-B

My cats breath smells of cat food.
indi
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: Earth, Brisbane, Australia
Posted: 17th Sep 2003 18:10
interesting. so why does it do it to a non textured cube?
does it carry the vertices anyway assuming they have to be there regardless. ?

http://www.lunarpixel.com
It's already tomorrow in Australia
Van B
Moderator
23
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 17th Sep 2003 18:38
If you make a cube in 3DS Max, then check the UV mapping, it's mapped with the whole texture on each face - so the vertices have UV mapping by default when you create them. Other modelling packages might be different, but it makes sense that you make a cube and can texture straight onto it without UV mapping first. So, if you imagine the UV data at each corner of a cube, you'd have the verts at the corner (number of verts depends on the orientation of the poly split), but the UV data would never match because each takes a different corner of the texture. The only truly identical verts are those at the poly split line, because they're simply being used to make a 2 poly plain, each plain is identical, but the edges and corners never match.

It's not a import or an export problem, there's nothing we can do about it - because without it UV mapping would be a nightmare on anything but a tileable texture.

In VANmesh, I'll give the option to ignore the UV mapping when importing, so the model could be created as a completely sealed unit, until your happy with it - but even then you'd have to split a line of verts so you could unwrap the texture onto 2D.

It's pretty hard to picture without the data laid out in front of you, I used to think the texturing and normals data was part of the poly, not the vert - every UV mapper has given me this impression. That's why texturing in VANmesh will be tackled differently - it makes sense to me that if you have verts with there own UV data, show the vert, show the poly using the vert, and let the user edit it in it's purest form if they like. It might not please everyone, but it'll let people see exactly how UV mapping works for a change.

I'm gonna see about ways to keep the smoothing groups - experiment with verts etc. I think the problem is not us, but modelling software having problems calculating normals when the verts have less connected verts to work with. I'm thinking vert linking as an alternative to welding, so there's 2 verts - but they'll act as if they'd been welded into 1.

This has been a very informative thread - cheers!, next time I'll stay on topic I promise.


Van-B

My cats breath smells of cat food.
JAT
23
Years of Service
User Offline
Joined: 7th Nov 2002
Location:
Posted: 17th Sep 2003 22:36
Van pretty much hit it on the head. In DirectX, The vertex data for one vertex is stored together in a structure. Each cube side needs a different normal as well as different texture coordinates, so there needs to be distinct vertices.

John Thompson
http://www.jtgame.com/jtedit
Dreamora
23
Years of Service
User Offline
Joined: 20th Sep 2002
Location: Switzerland
Posted: 18th Sep 2003 01:29 Edited at: 18th Sep 2003 02:11
sorry to say but UV mapping in .X format has nothing to do with vertices.

Vertices are saved as a numbered array, faces refer to this array and texture coordinates refer to the vertice array too as materials refer to the face array.
(just because mentioned: face normals would be such an array to, refering to the face array)

this means the vertice array is the base array for the whole model, the rest just needs to refer to it the right way.

so there is no real reason why this vertices have to be there multiple times, it's just up the exporter to create an ordered array and delete dublicates before exporting.


The problems seems to be the structure of the exporter of MS3D i think, as far as I can see out of the vertexorder, the vertices are written in face vertice order so there was no vertex dublication check in which prevented that something like this might happen.
Shadow Robert
23
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 18th Sep 2003 02:22
Quote: "sorry to say but UV mapping in .X format has nothing to do with vertices"


interesting ...

Quote: "Vertices are saved as a numbered array, faces refer to this array and texture coordinates refer to the vertice array too as materials refer to the face array.
(just because mentioned: face normals would be such an array to, refering to the face array)"


again interesting ... but the texture coordinate array must be the same size as the vertex array.

in other words you must have 8 uv vertex to 8 vertex, the only way to have more uv vertex than the real vertex is to export using multiple uv maps, each additional map allows you map^8 uv vertex to work with.
however if you go over 8 this can SERIOUSLY hinder the speed.

there is a very extensive DirectX Mesh Format help in the DirectX help

indi
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: Earth, Brisbane, Australia
Posted: 18th Sep 2003 03:09
so 3d canvas has this issue also, 24 vertices but truespace 3 it exports 14 vertices in binary or ascii with collapse mesh feature ticked or not on export.

http://www.lunarpixel.com
It's already tomorrow in Australia
Dreamora
23
Years of Service
User Offline
Joined: 20th Sep 2002
Location: Switzerland
Posted: 18th Sep 2003 04:16
ok the "nothing to do" was a bit a bad formulation.
It was meant compared to faces etc which uses the vertex indices to build up their structures.
JAT
23
Years of Service
User Offline
Joined: 7th Nov 2002
Location:
Posted: 18th Sep 2003 05:49
Ah, I understand now that you are talking about the vertices in the format, not the vertices loaded in the engine.

The exporter should try to minimize the number of vertex position entries, which it can do if the corresponding texture coordinate entries are not all unique for the same-positioned vertices. However, I may not have put in that optimization.

John Thompson
http://www.jtgame.com/jtedit
Dreamora
23
Years of Service
User Offline
Joined: 20th Sep 2002
Location: Switzerland
Posted: 18th Sep 2003 09:38 Edited at: 18th Sep 2003 09:38
Don't worry, DBPs loading routine as that worse that I don't think there is a real possibility to "optimize" it fully for DBP

That's why I'm hopping that at the DBO specifications are given out soon even if it only supports non-animated meshes. There are enough application possibilities for non-animated meshes it think and the earlier we have some ground specs the better the exporters will be ...
indi
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: Earth, Brisbane, Australia
Posted: 18th Sep 2003 10:08
I found a method that doesnt use 24 vertices.

amapi 515r to truespace2.cob then opening with truepsace3 and exporting to direct x results in 8 vertices and 12 polys and 1 texture colour.

http://www.lunarpixel.com
It's already tomorrow in Australia
Van B
Moderator
23
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 18th Sep 2003 11:39
Dreamflower,
I'm not sure what you mean - but I can guarantee that vertices hold more information than faces. Each vertice has it's position, it's normals, it's colour, and it's UV coordinates. The polygon list is only really there to tell the engine what vertices to make into polygons. It's more logical to give each vertice a 2D UV position than give each polygon 3 UV positions. Put this way, if each polygon held it's own unique UV data and normals data - that'd mean you'd have to edit the UV coordinates in neighboring polys too, which would involve a lot of data checking and vertice analysis. For example, you could delete every poly in a model, and if it allowed you to keep the vertice data - you could create the mesh again, with the same normals and UV data by simply joining up the vertices.

Indi,
What are you checking these things in? - you should check it with a textured model so you can see when the UV data gets kicked out of bed. I mean 8 vertices and 12 polys can't be textured because the 8 vertices could only possibly let you UV map 2 sides of the box. I'm guessing that the UV coords are all equal, like all at 0,0 so any twin verts can be optimised right down to the nitty-gritty, the 8 key vertice positions.


Van-B

My cats breath smells of cat food.
Dreamora
23
Years of Service
User Offline
Joined: 20th Sep 2002
Location: Switzerland
Posted: 18th Sep 2003 15:24
Sure vertices hold more informations, but DBP isn't able to parse them so why break heads about it? The models even break when you add vertex coloring (at least in V5.0)

Thats why I'm waiting for DBO format which is defined by TGC themselves then there won't be this damned problems with all exporters who play god and think they have the right to save the .x as the want

It's like back in DBC time when you tried to get animated X into DBC ... exactly 1 configuration for JTs old X exporter for MS3D worked, don't think any other exporter was even able to export them in DBC style.
Van B
Moderator
23
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 18th Sep 2003 15:54
Weird, vertice colours work for me - it think that when you load a mesh it gets rid of the vertice colours, but I am able to make meshes inside DBPro with vertice colouring. I'm looking forward to the DBO format too, should be damn easier than exporting .x or .3ds at least. There is always the internal memblock mesh format for non-animated meshes, texturing would have to be manual, but it's there and it's being used already (e.g. Kevils lightmap renderer). I agree though, it's pretty bad when the best way to convert to .X from .3DS - is the built in secret command in DBC or the 3DConv app supplied!.

Here's a quick question:
I can get the positions of each neighboring vertice a specified vertice is connected too, so I could specify a vert then work out the verts around it and calculate the average position. My idea is that I use this averaged location and the original vert location to calculate a normalisation vector. Is that the right approach to working out normals? - or is it more complex than that?. I should probably try it, but it is a lot of work just to find out it won't do the job.


Van-B

My cats breath smells of cat food.

Login to post a reply

Server time is: 2026-07-05 11:29:58
Your offset time is: 2026-07-05 11:29:58