Look, we've been declared officially nonexistent by the CIC!

Discuss the Wing Commander Series and find the latest information on the Wing Commander Universe privateer mod as well as the standalone mod Wasteland Incident project.
Post Reply
spiritplumber
Developer
Developer
Posts: 1831
Joined: Mon Mar 07, 2005 10:33 pm
Contact:

Look, we've been declared officially nonexistent by the CIC!

Post by spiritplumber »

http://www.crius.net/zone/showthread.php?t=20576 Should we tell them? ;)

(I've just gone over the cockpits and gun placements for all ships by the way,... we can use the WC1 ships, and some WC2 ships including the Strakha)
My Moral Code:
- The only sin is to treat people as if they were things.
- Rules were made for people, not the other way around.
- Don't deceive. Real life is complicated enough.
- If all else fails, smash stuff.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

I don't see any mention of us; maybe they edited the thread since you posted the link...

Hey, I'm busy right now with a personal project. You'd like it, as an EE, I'm sure; it's a PCB layout program... in 3D :D

Image

I can even move/rotate components, already...

Image
My optocoupler and resistor models aren't textured yet.

I will be coming back, tho; just right now I'm hot to trot on this thing. Did Dual leave a current version of the Hornet? I'd like to finish it if he can't; then get back to work on the carrier.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

Hey chuck, I just noticed, by the end you'll have enough experience with Ogre to help with the port!
Cool - would you please?
I really have to finish this damned scene manager...
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
mkruer
Site Administrator
Site Administrator
Posts: 1089
Joined: Thu Jan 02, 2003 10:07 am
Contact:

Post by mkruer »

That’s cool. If I am understanding you correctly this could be adapted to finish is one part of the proposed GUI where you have drag and drop parts on a 3d model.
I know you believe you understand what you think I said.
But I am not sure you realize that what you heard is not what I meant.

Wing Commander Universe Forum | Wiki
Wing Commander: The Wasteland Incident
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

klauss wrote:Hey chuck, I just noticed, by the end you'll have enough experience with Ogre to help with the port!
Cool - would you please?
I really have to finish this damned scene manager...
I've always been wanting to help; just that when I looked at Ogre the first time I found it rather huge, and couldn't get my head around it. In fact, I decided to use Ogre for this PCB thing precisely in order to learn it so I can help you with programming. The only problem is I haven't got my head around it yet; specially the materials, and shaders, and all that. And right now I'm reorganizing the program. Up to the point when I took the pics above, the entire program was in one file: the app's header file :)
But now I got myself caught in a bear trap of complexity; as I break up the program it cries out to be broken finer and finer. By now I have a huge tree of folders with software packages and subpackages and sub-sub-packages, in deeply nested namespaces... so I'm not doing anything graphical atm; --the program is far from even compiling, right now; and when I get back to graphics, first thing I'll want to do is make a single material and set of shaders, with a standard OGL fallback, for solid materials, that can be changed in appearance on the fly just by changing the textures, a la vegastrike engine: A set of textures defines a material. I have to warn you, last time I looked at your global illumination shaders I didn't understand the first thing; the math went right over my head. I could do some grunt work for you, though, if you have any.
mkruer wrote:That’s cool. If I am understanding you correctly this could be adapted to finish is one part of the proposed GUI where you have drag and drop parts on a 3d model.
You mean we're finally going to have ship design? Great! For sure!
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

Oh, yes... I'm trying to make the "Model" class be able to handle modular models, so you could indeed make a Drag & Drop model designer - even ingame, since all you have to do to make it usable is add the designed resource to their resource managers ( and make units use that model, of course, which is rather simple - setModel(), as I'm separating graphics from physics as much as possible ).

So... ship design all the way - but I warn you, the Model class won't handle (much of) the physics and functionality, so the editor will have to juggle both around, editing the graphical and physics model in parallel. Don't worry - when it's ready for usage (the framework), you'll have python examples, I think it was Ryder the one with the modular station idea (you too probably), and the first thing that will get done with the ability is probably make stations randomly evolve.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Allright; where's the present model class? I hope I don't have to dive into all the rest of the engine to do this. Basically, you want to turn Model into a Composite pattern, and have a gui for assembly? Also, at what level does this happen? Do the parts remain as sub-objects, or do they become part of it? I think they should remain sub-objects, if you want them to come apart in explosions, but then you need physics models that can change at run-time: The core part's physics changing as subobjects are inserted or removed...

Hey, by the way, first there was physX, and now there's an AI chip:
http://www.aiseek.com/Intia.html
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

The model class only bunches up graphical meshes and how they animate in a structured way (as in coming apart when blown up).

Right now, it's on my HD - the version in svn is quite outdated, but since I'm redesigning it a bit (the one in SVN didn't have modularity and fusion (*) as such a high-priority objective, so it needed a redesign), it doesn't even build right now, and I've been lacking both insight and time to finish the redesign and commit.

The problem redesigning is in performance - I want to have "observers" (can't remember what I called them, but observer is a good term - I'll probably rename it to that ;) ), pure-virtual classes you can subclass to create "parameter mappings" with plugins, so you can grab a unit, do some kind of processing, and apply it to a mesh prior to drawing. The objective? Flexibly map AI state to shader parameters, for visualization.

(*) Fusion stands for "Fuse points" - that's how you break things apart. Fusion uses a "structure" graph, with physical properties (on the physical side). The graphics side has a similar structure, and I'm trying to decouple the two structures but I'm having a hard time. That's the insight problem too. Ok, anyway, the idea is that the structure connects meshes together in a graph. Links may be articulated or not. When a node is applied a force, the links propagate the force up to a limit and, when a link is unable to, it breaks. Gameplay-wise, this means collisions are fatal by engine design, unless you use infinite-strength links. Graphics-wise, it means it's simple to spawn two (graphical) units out of one when a model breaks apart: you take the graph, pick a node, get all nodes reachable from that node, and that's one unit. Remove those nodes, take one node of the remaining ones, rinse and repeat. Simple, efficient algorithm that realistically breaks models apart. When you have a model spliced this way, you can add "break-apart momentum" in a realistic fashion as well. It's really neat, and I'm confident it will, by combining physics with graphics, result in realistic destructible structures. If, to each node, you add subsystem mappings, you can also model damage this way. I hate the unified form it's taking, since I want to separate graphics from physics, so if you have an idea regarding this problem I'm all ears.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

... classes you can subclass to create "parameter mappings" with plugins ... grab a unit ... apply it to a mesh ...Flexibly map AI state to shader parameters ...
* scratching head with both hands and feet...

Okay, let me have this Model class, see if I can figure out the code.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

Ok, when I get home (which is Late), I'll mail it along with some explanation of the idea behind the stuff.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

In the meantime, here's a really smart pointer for ya; a wolf in sheepskin...

Code: Select all

#ifndef _DARK_PTR_H_
#define _DARK_PTR_H_

//dark_ptr<>
//by chuck_starchaser
//modified auto_ptr that makes the pointer mutable, so as to be
//able to have a copy constructor with a const RHS argument,
//so that it can be used in stl containers (who really want to see
//standard copy constructors, so... Give 'em what they want!)
//try,
//class foo { .... };
//std::map< size_t, dark_ptr< std::map< size_t,  dark_ptr< foo > > > >
//no problemo :)

template< class T > class dark_ptr;

template< class T > struct dark_ptr_ref
{
	dark_ptr< T > const & ref;
	dark_ptr_ref( dark_ptr< T > const & other ): ref( other ){}
};

template< class T > class dark_ptr
{
	mutable T *ptr;
public:
	typedef T element_type;
	explicit dark_ptr( T *Ptr =0 ) //no throw
	: ptr( Ptr )
	{}
	dark_ptr( dark_ptr<T> const & other ) //no throw
	: ptr( other.dark_release() )
	{}
	dark_ptr( dark_ptr_ref< T > const other ) //no throw
	: ptr( other.ref.dark_release() )
	{}
	template< class U >
	operator dark_ptr< U >() //no throw
	{
		return dark_ptr< U >( *this );
	}
	template< class U >
	operator dark_ptr_ref< U >() //no throw
	{
		return dark_ptr_ref< U >( *this );
	}
	template< class U >
	dark_ptr< T >& operator=( dark_ptr< U > const & other ) //no throw
	{
		reset( other.dark_release() );
		return *this;
	}
	template< class U >
	dark_ptr( dark_ptr< U > const & other ) //no throw
	: ptr( other.dark_release() )
	{}
	dark_ptr< T >& operator=( dark_ptr<T> const & other ) //no throw
	{
		reset( other.dark_release() );
		return *this;
	}
	dark_ptr<T>& operator=( dark_ptr_ref<T> const & other ) //no throw
	{
		reset( other.ref.dark_release() );
		return *this;
	}
	~dark_ptr()
	{
		//testing for zero for performance reasons (the most
		//popular compiler takes 11 instructions to delete 0)
		if( ptr ) delete ptr;
	}
	T * dark_release() const //no throw
	{
		T *ptemp = ptr;
		ptr = 0;
		return ptemp;
	}
	void reset( T * Ptr =0 )
	{
		assert( ! ptr || ptr != Ptr );
		//testing for zero for performance reasons (the most
		//popular compiler takes 11 instructions to delete 0)
		if( ptr && ptr != Ptr ) delete ptr;
		ptr = Ptr;
	}
	T * get() const //no throw
	{
		return ptr;
	}
	T & operator*() const //no throw
	{
		return *ptr;
	}
	T * operator->() const //no throw
	{
		return &**this;
	}
	void swap( dark_ptr<T> & other ) //no throw
	{
		T * ptmp = other.ptr;
		other.ptr = ptr;
		ptr = ptmp;
	}
	operator bool () const //no throw
	{
		return ptr != 0;
	}
	bool operator! () const //no throw
	{
		return ptr == 0;
	}
private:
	template < const int I > bool operator==( const int I ) const; //dont exist
	template < const int I > bool operator!=( const int I ) const; //dont exist
public:
	template <> bool operator==< 0 >( const int I ) const //no throw
	{
		return ptr == 0;
	}
	template <> bool operator!=< 0 >( const int I ) const //no throw
	{
		return ptr != 0;
	}
};

template< class T > inline void swap( dark_ptr<T> & a, dark_ptr<T> & b ) //no throw
{
    a.swap(b);
}
template< class T > inline T * get_pointer( dark_ptr<T> const & p ) //no throw
{
    return p.get();
}


#endif

klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

Ogre's SharedPtr has all the niceties, plus reference counting.
(in fact, it's reference counting what gives the niceties).

Of course, you may not want that behavior - but still, it's usually a great option.
Otherwise - cool super-specific class you have. I wouldn't use it much, it is totally counter-intuitive, and error-prone because of that, but I bet you can code some safe (if you know who you're dealing with) and efficient stuff with that.

BTW: I'm making the model class commitable, and will commit it as soon as I finish - I mean, at least I'll make it build, forget about it making sense.
I'll mail you an explanation still, though, since I doubt the idea I posted before is easily visible in the code.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Yeah, my intent was to make an auto_ptr fit in stl containers, nothing fancier than that. Otherwise, might as well use boost's smart pointers. Shared ptr is fatter and slower, and has reference counted semantics. I only use reference counting with singletons, pretty much, and I can code the counting in 5 minutes without using shared_ptr's. I'm kind of scared of boost pointers; maybe because I never quite got my head around the way they can change the type of the pointer.
I admit this dark_ptr is a big lie, but for someone used to auto_ptr, and aware of the cheat, it won't make any difference whether to see const in the argument of the copy ctor, or not. The mascarade is targeted at the stl; not at the programmer; and it assumes the programmer is smarter than the stl :D
Very politically incorrect; that's why I called it dark_ptr; I was tempted to call it "bike_ptr", to differentiate it from "auto...", but that'd be like throwing gasoline at a fire...

Sounds like a good plan. I will be very busy with work, now, for a few days. The boards for the project I was working on are now assembled, or will be, as of this morning in fact; and I have to start testing my software (a motor control for plastic film wrapping, embedded C) so I'll be working full time on that for a few days; a week easily; so no rush atm.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

I just came across an interesting link:
http://www.humus.ca/index.php?page=3D&ID=69

Somebody usurped your GI trademark, klauss; look at this thread at Ogre:
http://www.ogre3d.org/phpBB2/viewtopic.php?t=24243
spiritplumber
Developer
Developer
Posts: 1831
Joined: Mon Mar 07, 2005 10:33 pm
Contact:

Post by spiritplumber »

shiny pictures!
My Moral Code:
- The only sin is to treat people as if they were things.
- Rules were made for people, not the other way around.
- Don't deceive. Real life is complicated enough.
- If all else fails, smash stuff.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

I'm not sure what you mean.
Those are completely different techniques for completely different situations.

Well... PRT is actually a great thing that we could use, but PRT requires complex baking applications. Right now, I don't know any PRT baker - but mostly, PRT requires an unsuitable preprocessing stage on the environment (the cubemap) - that's why I discarded PRT, it makes dynamic updates of the cubemap quite nasty.

Aside from PRT, the other techniques are all great but highly unsuitable for our needs. Dynamic lightmaps are resource hogs for us. We can't have a lightmap for every instance of every ship, and we can't update them as rapidly as we would (imagine a ship starts spinning). And though noisy GI smoothing is quite cool, and implementable (not through the techniques posted there, but I know a few others which map much better to GPU hardware), it would provide little benefit to our case, since we can't have true montecarlo implementations on a shader (AFAIK - we could investigate that possibility later, though).

Anyway... I think I had seen that thread already.
I hadn't read the papers though... cool stuff, and lots of ideas there.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

That was my whole intent: to pass that by you *just in case* you might find something helpful. Remember, I haven't the foggiest idea how your algorithm works. By the way, I think you should try and get a patent for it, for commercial uses, if there's any chance your method could be built into hardware. Nvidia and ATI got enough money already, and you could use a few millions, I'm sure.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

chuck_starchaser wrote:Nvidia and ATI got enough money already, and you could use a few millions, I'm sure.
Hehe... I'm happy with them paying all my expenses ;) - that would be cool.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Post Reply