39 replies to this topic

[npattinson]

Fixed the bug where if you closed a changed 3do window it wouldn't prompt you to save changes.
Added support for editing a couple more 3do items -

Deleting distance splitter children.
Change per-vertex colour for shaded polygons.

Nigel

[nes]

Thx Nigel for this tool

[Steffen W]

Thanks Nigel,


i just found how incredibly useful this tool is in watching car edits.

how can i make sensible use of the viewpoint window ? is there anyway that i can change it other than just axis wise? i saw the viepoint dialog window didnt let me change things and there was no center, rotate or zoom feature as e.g. in 3doeditor.


Steffen

[npattinson]

Steffen W, on May 21 2008, 10:06 AM, said:

how can i make sensible use of the viewpoint window ? is there anyway that i can change it other than just axis wise? i saw the viepoint dialog window didnt let me change things and there was no center, rotate or zoom feature as e.g. in 3doeditor.

Not currently - controlling the viewpoint is one of RaceCon's big weaknesses, which I meant to do something about but have never gotten around to. What do you consider a good example of how to handle this - 3doeditor, or is there something better ?

Nigel

[Steffen W]

npattinson, on May 21 2008, 01:26 AM, said:

Steffen W, on May 21 2008, 10:06 AM, said:

how can i make sensible use of the viewpoint window ? is there anyway that i can change it other than just axis wise? i saw the viepoint dialog window didnt let me change things and there was no center, rotate or zoom feature as e.g. in 3doeditor.

Not currently - controlling the viewpoint is one of RaceCon's big weaknesses, which I meant to do something about but have never gotten around to. What do you consider a good example of how to handle this - 3doeditor, or is there something better ?

Nigel

GPLEditor for example would be a not so good example, viewpoint selection is acceptable (doubleclick on vertex with shift pressed) but rotation with moving the mouse is horror.

3doEditor is a good example. doubleclick on vertex for vertex or polygon options, including setting this to the new viewcenter. additionally and this i find most useful zoom and east west and nort-south rotation controls at the window bottom.
what would be a good enhancement over 3doEditor is that rotation is not only possible around the origin but also around the vertex selected as viewcenter, good to check details. or to keep things simple only rotation around the vertex selected as viewcenter and origin being a possible default viewcenter even if there is no vertex at 0 0 0. but maybe rotation around anything else but origin is difficult to implement. in case so the basic 3doEditor funcionality would be of great help already.

your threads always turn into some christmas gift wishlists

Steffen

Edited by Steffen W, May 20 2008 - 05:57 PM.

[nes]

Hi Nigel, I told you before that this it´s a good tool for editing GPL.
Now we change some *.3do in the main track, and don´t need to change it in every layer (distance view or section track). This program do it selves when you change it on one place.
But this don´t happen with the mips too.
When you change a *.mip (ex: asphalt.mip to asphal2.mip) in a section of track, it don´t change automatic in the others distance points. Must to change step by step on every distance view.
Can this be changed, maybe can be faster editing, if it´s posible to solve this.

thx in avance

_nes

[npattinson]

nes, on May 24 2008, 11:56 PM, said:

Now we change some *.3do in the main track, and don´t need to change it in every layer (distance view or section track). This program do it selves when you change it on one place.
But this don´t happen with the mips too.
When you change a *.mip (ex: asphalt.mip to asphal2.mip) in a section of track, it don´t change automatic in the others distance points. Must to change step by step on every distance view.
Can this be changed, maybe can be faster editing, if it´s posible to solve this.

I think that's something I'm unlikely to change in the forseeable future, RaceCon will probably stick to simple changes that affect only the current node.

Nigel

[nes]

Ok, thx Nigel.
Still it is a wonderfull tool  

[Luna]

Can I make a few requests for additional features?

When editing vertex colours:
- an option to use hexadecimal values, and/or a 0-255 scale.
- the ability to change all vertex colours at once for each polygon, i.e enter an rgb value and all vertex colours for the current poly are set to this value.

Also...
- edit poly colour.
- edit texture co-ordinates.
- change poly type, and keep any values in tact. E.g change an 81f to an 820 and keep all texture-cords and poly colour; or change textured to untextured and keep poly colour. Not sure how complicated this would be to implement..
- edit offsets for child nodes.


BTW I've just noticed that the plane selectors are 'upside down' - what you have as the "far child" is actually the "near child" and vice versa; similarly the front/back children for flavour8 nodes are named the wrong way round.

[npattinson]

Luna, on Jun 2 2008, 01:50 AM, said:

When editing vertex colours:
- an option to use hexadecimal values, and/or a 0-255 scale.

I'd rather leave this as it is - my code uses floating point values for colours everywhere, so if I did provide the alternatives they'd immediately get converted back to floating point anyway.

Luna, on Jun 2 2008, 01:50 AM, said:

- the ability to change all vertex colours at once for each polygon, i.e enter an rgb value and all vertex colours for the current poly are set to this value.

Assuming I add the support for changing polygon types, is this still useful ? This would just result in an unshaded polygon.

Luna, on Jun 2 2008, 01:50 AM, said:

- edit poly colour.
- edit texture co-ordinates.
- change poly type, and keep any values in tact. E.g change an 81f to an 820 and keep all texture-cords and poly colour; or change textured to untextured and keep poly colour. Not sure how complicated this would be to implement..

I think I should be able to do these.

Luna, on Jun 2 2008, 01:50 AM, said:

- edit offsets for child nodes.

You'll probably need to be more specific here, as they'll need separate coding for each type, and doing them all would take a while.

Luna, on Jun 2 2008, 01:50 AM, said:

BTW I've just noticed that the plane selectors are 'upside down' - what you have as the "far child" is actually the "near child" and vice versa; similarly the front/back children for flavour8 nodes are named the wrong way round.

I think that depends on your point of view. For instance with the simplest of the plane nodes, the one with only one child, I call that child node the 'front' node. To me that makes sense because if you view it from the intended side, you're seeing what's on the front side of the plane which is the child node. If you switch to the wrong side you don't see anything. With respect to the plane equation, it turns out that means that if the equation result is positive you're viewing from the front side, if it's negative you're viewing from the back side. I think all the rest of the child nodes are then named in a consistent fashion, taking a positive plane equation result to be the front and a negative result to be the back.

Possibly the way I name the nodes adds a bit of confusion, e.g. I call the simplest type "Plane Cull Front". That's not meant to mean that it culls the front side per se, merely that the child node called 'Front' is a candidate for culling, and won't be drawn when due to the viewpoint it has become the back.

That was probably clear as mud

Nigel

[Luna]

npattinson, on Jun 9 2008, 02:11 AM, said:

Luna, on Jun 2 2008, 01:50 AM, said:

When editing vertex colours:
- an option to use hexadecimal values, and/or a 0-255 scale.

I'd rather leave this as it is - my code uses floating point values for colours everywhere, so if I did provide the alternatives they'd immediately get converted back to floating point anyway.

I was thinking it might be easier from a user's point of view - I'm more familiar with rgb values in hex or 0-255 than in decimal. This is probably largely due to the fact that until now I've had to use a hex editor to to alter vertex colours; but also most graphics software uses hex or 0-255 for colour - I don't have any that uses decimal.  

Quote

Luna, on Jun 2 2008, 01:50 AM, said:

- the ability to change all vertex colours at once for each polygon, i.e enter an rgb value and all vertex colours for the current poly are set to this value.

Assuming I add the support for changing polygon types, is this still useful ? This would just result in an unshaded polygon.

When shading 3dos I often find I want to shade a polygon all the same colour. So to shade a triangle red, for example, I need to set the colours of each of the 3 vertices to the same rgb value. I'd find it useful to be able to just set the rgb once and have it 'copied' to all the vertices which make up the polygon.

Quote

Luna, on Jun 2 2008, 01:50 AM, said:

- edit offsets for child nodes.

You'll probably need to be more specific here, as they'll need separate coding for each type, and doing them all would take a while.

What I mean is changing the offsets to point to other parts of the tree. For example in a two-child plane selector you could edit the offsets for both children to be the same, rather than duplicating the entire contents of one child in the other. Admittedly this probably isn't something which would be used very often.

Quote

Luna, on Jun 2 2008, 01:50 AM, said:

BTW I've just noticed that the plane selectors are 'upside down' - what you have as the "far child" is actually the "near child" and vice versa; similarly the front/back children for flavour8 nodes are named the wrong way round.

I think that depends on your point of view. For instance with the simplest of the plane nodes, the one with only one child, I call that child node the 'front' node. To me that makes sense because if you view it from the intended side, you're seeing what's on the front side of the plane which is the child node. If you switch to the wrong side you don't see anything. With respect to the plane equation, it turns out that means that if the equation result is positive you're viewing from the front side, if it's negative you're viewing from the back side. I think all the rest of the child nodes are then named in a consistent fashion, taking a positive plane equation result to be the front and a negative result to be the back.

I think front/near/above etc. mean on the side of the plane in which it's facing, irrespective of whether it's facing positively or negatively. For example in a flavour9 node the first child is seen when the viewer is above the plane, even if the plane equation results in a negative value (consider a cube 3do). In RaceCon the first child of a flavour9 is consistently called the "far child" but I think it should be called the "near child" because its contents are what can be seen when the viewer is above the plane.. In a flavour8 node the second child should be 'on the plane when seen from above the plane', i.e the "front child". This completely threw me when I was editing vertex colours for polys in these positions as I ended up shading the wrong side...

[npattinson]

Updated version downloadable from first post.

GPL node type 5.17 (the main one used in car skin 3dos) is now editable. The mip names can be changed, and by clicking on the MIP Count you can change the count, either increasing or decreasing the number of mips.

I also fixed some bugs in the saving code of some of the lesser used node types.

Nigel

[npattinson]

Updated version downloadable from first post.

One tiny change - a check that was performed when loading 3dos has been switched to only complaining if the 'strict' option is turned on.

Nigel

[MECH]

Hi Nigel,

I've had much benefit from you program  

I have a question regarding the saving of changes:
Is there some sort of clean up function in it? I noticed it removed unused vertices. I hadn't used those vertices in any polygon yet as i was correcting something else. I'm aware that it recreates the 3do since all id's get scrambled afterwards but didn't notice the other feature until confronted with it  

If so this might be useful for cleaning up some 3do's with clutter.   (although i now there's this 3doclean utility but it involves Dos, batchfiles or manual labour)

Btw, does it also clean up STRN references? E.g. if i remove the head srb's in the car 3do nodes will it also remove the STRN reference? Since we use 3d helmets for Can Am i'ld like to clean up the car.3do as much as possible  

Thx, again.

Edited by MECH, Aug 26 2008 - 04:57 AM.

[npattinson]

MECH, on Aug 26 2008, 05:43 AM, said:

I have a question regarding the saving of changes:
Is there some sort of clean up function in it? I noticed it removed unused vertices. I hadn't used those vertices in any polygon yet as i was correcting something else. I'm aware that it recreates the 3do since all id's get scrambled afterwards but didn't notice the other feature until confronted with it  

If so this might be useful for cleaning up some 3do's with clutter.   (although i now there's this 3doclean utility but it involves Dos, batchfiles or manual labour)

Btw, does it also clean up STRN references? E.g. if i remove the head srb's in the car 3do nodes will it also remove the STRN reference? Since we use 3d helmets for Can Am i'ld like to clean up the car.3do as much as possible  

Yes, I added this in recently - it cleans up unused vertices, planes, normals and strings. I'm slightly less sure about orphaned nodes - I think it will clean them up as well, but if so that's something it has always done and not something I've changed recently.

Nigel