next »

[bateleur]

I can't tell where the line numbers fall, but the first thing which strikes me about this code is that if an element of tri is an object with a field called "index1" then it's something which needs instantiating. You have this line:

Code:

tri = new triangle[m.triangles.Length/3];

...but I don't see anywhere that populates this array with instances of 'triangle'. Until you do that, each element of tri will be null, not a tri.

(Sorry for the cumbersome wording. TIGforums appears not to support noparse, so I can't type "tri [ i ]" without the spaces or it interprets it as me wanting italics.)

[oahda]

Relevant tip: unike in C++, there is a meaningful difference between a struct and a class in C#. You might want a struct here instead. Objects from structs cannot be null, and are passed by value. Objects from classes can be null and are passed by reference. You probably don't need those features here, so you might want to use a struct, in which case I believe you won't manually have to set each array element to be a new object, as they'll have been initialised anyway since they can't be null if you use a struct instead of a class.

[gimymblert]

...but I don't see anywhere that populates this array with instances of 'triangle'. Until you do that, each element of tri will be null, not a tri.

Hello! I'm dum, how are you?

Relevant tip: unike in C++, there is a meaningful difference between a struct and a class in C#. You might want a struct here instead. Objects from structs cannot be null, and are passed by value. Objects from classes can be null and are passed by reference. You probably don't need those features here, so you might want to use a struct, in which case I believe you won't manually have to set each array element to be a new object, as they'll have been initialised anyway since they can't be null if you use a struct instead of a class.

I hear you, the reality is that it is an artifact of prototyping, also because I don't have enough coding experience, since I don't code continually.

What happen is that I'm going for implementing half edge structures, but half edge declaration has reference to half edge in the body, and it threw me away warning because of self referencing (potential recursion? if it's value it's not a problem) So I switched to class to make them disappear (and that make sense half edge are using reference to), I haven't investigated since and stuck to class for everything preemptively.

SO there will be refactoring and documentation to do once I have test that the basic half edge is done. The code now is to translate typical mesh into half edge, so I'm going through validation step to be sure I got everything right. The code above is about extracting triangle, then I will extract regular edge, then turn that into half edge, then  I will refactor to extract from mesh data without intermediate representation like the triangle above.

I need this to complete an implementation of convex hull. Which is needed to have an implementation of blender's skin modifier, which is needed for a creature editor like  spore.

[oahda]

That sounds cool! Will you be posting about it somewhere if you get it working?

[Photon]

Code:

src/game/BasicPhysicsSys.hx:98: characters 3-39 : haxe.ds.GenericStack<aurora.collision.IntersectionTracker<game.CollisionGroup>> should be
 haxe.ds.GenericStack_aurora_collision_IntersectionTracker_game_CollisionGroup
Build halted with errors.

I'm confused. Why is it treating two stacks of the same type as different types? I'm not even sure where the latter "underscore" type in that error statement is coming from. That should be the temporary variable I declared for the equality, but for some reason its been converted into something else?

[InfiniteStateMachine]

I wonder if haxe squashes down the name for generics and those are actually the same type.

[Photon]

I know I've read about that, but I had thought that you had to specify @:generic for that to happen. That being said, it is a standard library type we're talking about, and a quick check confirms that GenericStack does use @:generic.

I assume that the type templating then is what's causing the compiler to get confused. But perhaps if I made the IntersectionTracker generic as well?

...

OK, so I had to tag several related classes, but it does work now. So the problem came from multiple levels of templating and conceptually using the stack in both a generic and non-generic format:

Code:

class ObjectA<T> {
    public var stack:GenericStack<T>
}

class ObjectB<T> {
    public var obj:ObjectA<T>
}

ObjectA recognizes the stack as its "generic" transformation. ObjectB, on the other hand, apparently cannot because ObjectA itself is not a generic and therefore retains its type amibiguity. It appears then that, by extension, ObjectB can only understand the underlying stack variable using the same amibiguity. Thus, a compiler error when you try to equate a generic with a non-generic, even though they are conceptually the same. Just in case I'm not making myself clear:

Code:

var x:ObjectB<Int> = new ObjectB<Int>();
var temp_stack:GenericStack<Int>;

temp_stack = x.obj.stack; // compiler error

Clearly, both temp_stack and ObjectA's stack member are the same type. Unfortunately, seen through ObjectB's lens, ObjectA's stack is not a generic but an extension of non-generic ObjectA's typing; it doesn't see ObjectA's stack as a generic type but a non-generic. So again, compiler error.

That being said... if you avoid the "scope" issue above (in this instance, reference the stack directly instead of trying to assign it) you avoid errors. I almost wonder if this could be considered a bug with the compiler? Should it be equating the two types underneath the hood? Just a thought.

Anyway, hopefully this won't bite me in the rear end later. Performance wise its shouldn't be a problem since the collision code this is a part of should only have one feasible type anyway (an enumeration defining collision groups.)

[gimymblert]

That sounds cool! Will you be posting about it somewhere if you get it working?

Of course, if only I complete it, I'm significantly dumber that I use to be, especially after my depression. I know this because I get stumped on easy task I use to do in the past.

[InfiniteStateMachine]

I know I've read about that, but I had thought that you had to specify @:generic for that to happen. That being said, it is a standard library type we're talking about, and a quick check confirms that GenericStack does use @:generic.

I assume that the type templating then is what's causing the compiler to get confused. But perhaps if I made the IntersectionTracker generic as well?

...

OK, so I had to tag several related classes, but it does work now. So the problem came from multiple levels of templating and conceptually using the stack in both a generic and non-generic format:

Code:

class ObjectA<T> {
    public var stack:GenericStack<T>
}

class ObjectB<T> {
    public var obj:ObjectA<T>
}

ObjectA recognizes the stack as its "generic" transformation. ObjectB, on the other hand, apparently cannot because ObjectA itself is not a generic and therefore retains its type amibiguity. It appears then that, by extension, ObjectB can only understand the underlying stack variable using the same amibiguity. Thus, a compiler error when you try to equate a generic with a non-generic, even though they are conceptually the same. Just in case I'm not making myself clear:

Code:

var x:ObjectB<Int> = new ObjectB<Int>();
var temp_stack:GenericStack<Int>;

temp_stack = x.obj.stack; // compiler error

Clearly, both temp_stack and ObjectA's stack member are the same type. Unfortunately, seen through ObjectB's lens, ObjectA's stack is not a generic but an extension of non-generic ObjectA's typing; it doesn't see ObjectA's stack as a generic type but a non-generic. So again, compiler error.

That being said... if you avoid the "scope" issue above (in this instance, reference the stack directly instead of trying to assign it) you avoid errors. I almost wonder if this could be considered a bug with the compiler? Should it be equating the two types underneath the hood? Just a thought.

Anyway, hopefully this won't bite me in the rear end later. Performance wise its shouldn't be a problem since the collision code this is a part of should only have one feasible type anyway (an enumeration defining collision groups.)

Nice catch. I'll have to try to keep that in mind when I'm using generics in Haxe. That's one of those things I can see making me go down a lot of wrong paths trying to solve.

It sounds reasonable that the system isn't powerful enough to figure that out. I'm not sure how difficult a problem that is to solve but the language is maintained pretty much by one person. Considering that fact I'm amazed how functional it is

[zilluss]

structs cannot be null, and are passed by value. Objects from classes can be null and are passed by reference.

This is a common misconception, that also exists for Java.
Objects are passed by value. This means that assignments to the passed objects only affect the object reference in the function, unless you prefix it with the ref (or out) keyword, which makes it a reference.

[Photon]

Does anyone have any general pointers on selecting a (base) game resolution?

[DragonDePlatino]

Go for anything with a 16:9 ratio. It'll fit both 1080p and 4k resolutions. If you are upscaling pixel art, use a resolution that cleanly upscales to 1080p like 960x540, 640x360, 480x270, 384x216 or at the absolute minimum, 320x180. The latter three are probably best-reserved for mobile games as they're a little on the restrictive side.

[oahda]

structs cannot be null, and are passed by value. Objects from classes can be null and are passed by reference.

This is a common misconception, that also exists for Java.
Objects are passed by value. This means that assignments to the passed objects only affect the object reference in the function, unless you prefix it with the ref (or out) keyword, which makes it a reference.

Yeah, I know that really "objects are passed by value and you get a different reference to the same data", but since in practice this usually implies the expected "pass by reference" behaviour, I find this to be unnecessary pedantry for most purposes, which rarely helps give people who aren't fully familiar with everything yet a clearer idea, but rather the opposite.

It's mostly only really relevant in the cases where said ref keyword is desired to actually point or fill a particular reference to/with something else, and that's relatively rare. A versed C# programmer should of course be aware of it (and maybe sometimes make use of the fact), but I don't think it's essential to begin with, and since I'm not sure what level Gimmy's at, it didn't feel relevant here, only potentially unnecessarily confusing.

By value or not, there's a reference/pointer/indirection/whatever involved when it comes to class instances but not when it comes to struct instances, which is the important difference that has the relevant implications that I wanted to stress.

[zilluss]

The problem is when you tell beginners that objects are passed by reference and they discover the ref keyword, they'll have to unlearn what they've learned. Instead I would make the distinction between reference and value types (like the C# Reference manual does) and don't go into passing. That way you can also explain the String-class paradox btw.

I don't try to be nitpicky or an asshole, I just can remember extremely well what I've struggled with as a beginner, and dealing with unlearning things because of inaccurate or wrong information was a huge problem.

[oahda]

Yeah, I mostly felt the silly need to defend my pride by showing that I actually did know how it works.

Can't really argue for or against your opinion on teaching. I'm still conflicted as to how beginners should be taught and I feel I go about it differently every time on the rare occasion that I do get the opportunity. Plus it differs from language to language anyway. I guess I'd prefer to focus on programming itself rather than a particular language, but that might be difficult when it comes to actually getting anything done in a particular language... Also depends on the learner, and whether they know programming in a different language from before, or are just starting out, I'd say.

[InfiniteStateMachine]

I'd argue that maybe c# isn't the best language to introduce someone to programming in the first place. It throws too much stuff at you that you can't really ignore.

[oahda]

Yeah, I was thinking the same thing. I keep coming back to Python when I try to think of a good beginner's language. Looking at the indentation produced by most newcomers to C-style languages, it's a nice bonus that it enforces good habits there as well. I'd prefer it if Python wasn't dynamically typed tho. I think it's good for new programmers to be aware of what kind of data they're trying to manipulate, so they don't get weird and to them surprising errors.

[gimymblert]

This discussion about beginner have me wondering something lol AM I?
Technically I have been programming for at least 19+ years across many language BUT it wasn't big complete stuff, and those 19 years are rather loose and spotty, I more or less focus on prototyping features and validating idea. That's very different from programming continuously.

To me it seems that there is two level of programming, features and architectures, in practice the difference aren't clear cut, but those are perspective that help me find the right angle. Features is about capability, short term and is focused, there is a right way to do it, its like a puzzle. Architectures is about suitability, it's long term and loose, you need to make trade off to complete it, it's like a management game.

For a long time programming was to me about features, because I was doing incomplete stuff. Now I'm moving to complete project I see that biting me in the ass, as I have to handle a completely new approach. In the last 3 years, thanks to trying to program a menu, I started making a difference between those two notions. Menu is interesting, it's dirt simple as a features in isolation, but it has deep reaching implication for someone who learn thing through feature's perspective. Feature are self contain with generally a fixed footprint, you give it stuff and spit out stuff. Menu on the other hand must work with many system, generally through interruption and if you go fancy things go south very quickly (loading arbitrary number of arbitrary stuff in an inventory system), in my experience this even affect the game design, so getting this wrong can mean redesigning the game from bottom up and rethink the asset production, which as a lone dev was truly unprepared for.

To come back to the discussion, I think the model of unlearning stuff is feature driven, you do what it is capable to get result, learning nuance ahead is more suitable to architecture driven process, where you need to anticipate. Of course it fit both style of learner, getting shit down now or anticipating stuff ahead fit different kind of beginner.

I'm totally a beginner.

[gimymblert]

BTW I'm struggling with recursive reference now lol

I have validated the code of edges and triangles (faces) extraction.

Code:

using UnityEngine;
using System.Collections;

public class mesh2Hedges : MonoBehaviour {

	public Mesh UnityMesh;
	public GameObject GO;
	
	triangle[] trianglelist;
	medge[] edgelist;
	
	public class triangle
	{
		public int index1 = 0,index2 = 0, index3 = 0;
		public Vector3 pos1, pos2, pos3, barycentre;
	}
	
	private class medge
	{
		public int index1, index2;
		public Vector3 pos1,pos2;
	}
	
	void CreateTriangleFromMesh(Mesh m)
	{
		trianglelist = new triangle[m.triangles.Length/3];
		
		int i = 0;while (i < trianglelist.Length)
		{
			int x = i*3;
			
			trianglelist[i] = new triangle();
			
			trianglelist[i].index1 = m.triangles[x];
			trianglelist[i].index2 = m.triangles[x+1];
			trianglelist[i].index3 = m.triangles[x+2];
			
			trianglelist[i].pos1 = m.vertices[trianglelist[i].index1];
			trianglelist[i].pos2 = m.vertices[trianglelist[i].index2];
			trianglelist[i].pos3 = m.vertices[trianglelist[i].index3];
			
			i++;
		}
		
	}
	
	void CreateMeshEdge()
	{
		edgelist = new medge[trianglelist.Length*3];

		int i = 0; while (i < trianglelist.Length)
		{
			int x = i*3;
			
			edgelist[x] = new medge();
			edgelist[x].index1 = trianglelist[i].index1;
			edgelist[x].index2 = trianglelist[i].index2;
			edgelist[x].pos1 = trianglelist[i].pos1;
			edgelist[x].pos2 = trianglelist[i].pos2;
			
			edgelist[x+1] = new medge();
			edgelist[x+1].index1 = trianglelist[i].index2;
			edgelist[x+1].index2 = trianglelist[i].index3;
			edgelist[x+1].pos1 = trianglelist[i].pos2;
			edgelist[x+1].pos2 = trianglelist[i].pos3;
			
			edgelist[x+2] = new medge();
			edgelist[x+2].index1 = trianglelist[i].index3;
			edgelist[x+2].index2 = trianglelist[i].index1;
			edgelist[x+2].pos1 = trianglelist[i].pos3;
			edgelist[x+2].pos2 = trianglelist[i].pos1;
						
			i++;
		}
	}
	
	
	
	void Start ()
	{
		GO = this.gameObject;
		UnityMesh = this.GO.GetComponent<MeshFilter>().mesh;
		
		if (UnityMesh != null) CreateTriangleFromMesh(UnityMesh);
		if (UnityMesh != null) CreateMeshEdge();
		if (UnityMesh == null)print("xx");
	}
	
	void Update ()
    {
	    Debug.DrawLine (Vector3.zero,Vector3.one*1000);
	    int f = 11;
	    foreach (triangle t in trianglelist)
	    {
	    	Debug.DrawLine(t.pos1*f,t.pos2*f,Color.red);
	    	Debug.DrawLine(t.pos2*f,t.pos3*f,Color.red);
	    	Debug.DrawLine(t.pos3*f,t.pos1*f,Color.red);
	    }
	    foreach (medge e in edgelist)
	    {
	    	Debug.DrawLine(e.pos1,e.pos2,Color.blue);
	    }
    }
	
	
}

Now I'm trying to turn it into half edge:

Code:

//-----------------------------------------------
	class half
	{
		public class face
		{
			public half.edge edge;
			public medge medge;
		}
		
		public class edge
		{
			public half.vert endvert;
			public half.edge twinedge;
			public medge twinmedge;
			public half.face face;
			public half.edge nexthalfedge;
			public medge nextmedge;
			
		}
		
		public class vert
		{
			public Vector3 position;
			public half.edge edge;
			public medge medge;
		}
	}
	

	half.edge[] hedge;
	half.face[] hface;
	half.vert[] hvert;
	
	void CreateHalfGeometry()
	{
		hedge = new half.edge[edgelist.Length];
		hface = new half.face[trianglelist.Length];
		hvert = new half.vert[UnityMesh.vertexCount];
		
		int i =0;
		i = 0; while (i < hedge.Length)
		{
			hedge[i] = new half.edge();
			i++;
		}
		i = 0; while (i < hface.Length)
		{
			hface[i] = new half.face();
			i++;
		}
		i = 0; while (i < hvert.Length)
		{
			hvert[i] = new half.vert();
			i++;
		}
		
		//enumerate face
		//enumerate edge
		//every face there is 3 edges, I only need one edge per face
		i = 0; while (i < hface.Length)
		{
			hface[i].edge.endvert.medge		= edgelist[i*3];						
			i++;
		}
		
		
	}
	
	void EnumerateEdge()
	{
		int i=0;
		//find edge that are similar, then are reverse
		
		//similar
		//if (edgelist[i].index1 == edgelist[i].index1 
		//&& edgelist[i].index2 == edgelist[i].index2)
		//-----check also position to find separation (same pos !index)
		
		//twin
		//if (edgelist[i].index1 == edgelist[i].index2 
		//&& edgelist[i].index2 == edgelist[i].index1)
	}

Like you see the half class is made of circular reference:
to update half.face, I need to update half.edge, which mean I need to update edge twice and face and vert 
Right now my brain is blanking, I don't think it should be that hard, the idea is that I partially fill the class member and iteratively complete them. Except I don't see the exact process yet.

I generally avoid circular logic like that whenever possible due to so call menu incident I had previously, I always try to have a flat dependency with low coupling whenever possible. Circular reference thing give me nightmare literally 

[gimymblert]

I have a doubt and wonder if my paragraph read a bit harsh lol If so it's not intended, I was explaining how and why I was a beginner in my mind, lol but mad socialz skills.